mail archive of the rauc mailing list
 help / color / mirror / Atom feed
* [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
@ 2021-07-22 12:11 Brian Hutchinson
  2021-07-22 12:16 ` Jan Lübbe
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Hutchinson @ 2021-07-22 12:11 UTC (permalink / raw)
  To: rauc


[-- Attachment #1.1: Type: text/plain, Size: 703 bytes --]

Hello again,

I'm wanting to have a rootfs that is read-only SquashFS and a appfs that is
encrypted.

And I'm kind of stumped.  I've searched the Documentation and archives and
it doesn't look like RAUC has native support for encrypted partitions but
in the archives I saw where one gentleman needed to create encrypted
bundles so this might be similar to my problem.

I know a bundle can have pre and post triggers so maybe I can use those to
cryptsetup luksOpen the partition and then mount it and then RAUC can do
it's normal thing ... but I've not researched that enough to know if that's
the way to go so thought I'd ask for some guidance to point me in the right
direction first.

Regards,

Brian

[-- Attachment #1.2: Type: text/html, Size: 893 bytes --]

[-- Attachment #2: Type: text/plain, Size: 66 bytes --]

_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
  2021-07-22 12:11 [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it Brian Hutchinson
@ 2021-07-22 12:16 ` Jan Lübbe
       [not found]   ` <CAFZh4h8Hd+sBBNz9m1ZJvnHEg9hsL4R19cmKJ21Y9Asiss2B5Q@mail.gmail.com>
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Lübbe @ 2021-07-22 12:16 UTC (permalink / raw)
  To: Brian Hutchinson, rauc

On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote:
> Hello again,

Hi!

> I'm wanting to have a rootfs that is read-only SquashFS and a appfs that is
> encrypted.

I assume you want to have a A/B appfs.

How do you encrypt your appfs? dm-crypt or fscrypt?

> And I'm kind of stumped.  I've searched the Documentation and archives and it
> doesn't look like RAUC has native support for encrypted partitions but in the
> archives I saw where one gentleman needed to create encrypted bundles so this
> might be similar to my problem.

Bundle encryption is independent of encryption in the rest of the system.

> I know a bundle can have pre and post triggers so maybe I can use those to
> cryptsetup luksOpen the partition and then mount it and then RAUC can do it's
> normal thing ... but I've not researched that enough to know if that's the way
> to go so thought I'd ask for some guidance to point me in the right direction
> first.

If you use dm-crypt, you can just use the device-mapper path for the slot's
device= propert in system.conf. That way, the encryption is transparent to rauc.

Regards,
Jna
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
       [not found]   ` <CAFZh4h8Hd+sBBNz9m1ZJvnHEg9hsL4R19cmKJ21Y9Asiss2B5Q@mail.gmail.com>
@ 2021-07-23 12:45     ` Brian Hutchinson
  2021-07-23 13:40     ` Jan Lübbe
  1 sibling, 0 replies; 9+ messages in thread
From: Brian Hutchinson @ 2021-07-23 12:45 UTC (permalink / raw)
  To: Jan Lübbe, rauc


[-- Attachment #1.1: Type: text/plain, Size: 2617 bytes --]

On Thu, Jul 22, 2021 at 8:55 AM Brian Hutchinson <b.hutchman@gmail.com>
wrote:

>
> Hi Jan,
> D
> On Thu, Jul 22, 2021 at 8:16 AM Jan Lübbe <jlu@pengutronix.de> wrote:
>
>> On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote:
>> > Hello again,
>>
>> Hi!
>>
>> > I'm wanting to have a rootfs that is read-only SquashFS and a appfs
>> that is
>> > encrypted.
>>
>> I assume you want to have a A/B appfs.
>>
>
> Yes, have A/B for Kernel, dtb, rootfs and appfs.
>
>
>> How do you encrypt your appfs? dm-crypt or fscrypt?
>>
>
> So process in factory will set everything up on eMMC the first time with:
>
> cryptsetup luksFormat /dev/mmcblk2p1 & /dev/mmcblk2p2
> cryptsetup luksOpen /dev/mmcblk2p1 crypt_appfs1 (same thing for
> /dev/mmcblk2p2)
> mkfs.ext4 /dev/mapper/crypt_appfs1 & crypt_appfs2
>
> Then in normal use just have a script that figures out which slots we are
> starting, A or B to determine with appfs partition to use and cryptsetup
> luksOpen then mount /dev/mapper.
>
>
>
>> > And I'm kind of stumped.  I've searched the Documentation and archives
>> and it
>> > doesn't look like RAUC has native support for encrypted partitions but
>> in the
>> > archives I saw where one gentleman needed to create encrypted bundles
>> so this
>> > might be similar to my problem.
>>
>> Bundle encryption is independent of encryption in the rest of the system.
>>
>> > I know a bundle can have pre and post triggers so maybe I can use those
>> to
>> > cryptsetup luksOpen the partition and then mount it and then RAUC can
>> do it's
>> > normal thing ... but I've not researched that enough to know if that's
>> the way
>> > to go so thought I'd ask for some guidance to point me in the right
>> direction
>> > first.
>>
>> If you use dm-crypt, you can just use the device-mapper path for the
>> slot's
>> device= propert in system.conf. That way, the encryption is transparent
>> to rauc.
>>
>
> Not following how that would work since the inactive appfs would be
> "closed/encrypted".
>
> Thanks!
>
> Regards,
>
> Brian
>
>
Sorry, forgot to reply-all to last message.  So when I did my luksFormat
etc., I used a key-file that I created with openssl rand -base64 32 >
luks_appfs_key.  Are you telling me that if I add a key and put it in the
rauc key ring in /etc/rauc and in my system.conf refer to my appfs by
/dev/mapper name rauc will know what to do to "open" the inactive appfs to
do the update?

I guess I'm hung up on how the "open" will take place and how to tell rauc
about the key to use etc.

Regards,

Brian

[-- Attachment #1.2: Type: text/html, Size: 4700 bytes --]

[-- Attachment #2: Type: text/plain, Size: 66 bytes --]

_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
       [not found]   ` <CAFZh4h8Hd+sBBNz9m1ZJvnHEg9hsL4R19cmKJ21Y9Asiss2B5Q@mail.gmail.com>
  2021-07-23 12:45     ` Brian Hutchinson
@ 2021-07-23 13:40     ` Jan Lübbe
  2021-07-30 13:33       ` Brian Hutchinson
  1 sibling, 1 reply; 9+ messages in thread
From: Jan Lübbe @ 2021-07-23 13:40 UTC (permalink / raw)
  To: Brian Hutchinson; +Cc: rauc

Hi Brian,

On Thu, 2021-07-22 at 08:55 -0400, Brian Hutchinson wrote:
> Hi Jan,
> 
> On Thu, Jul 22, 2021 at 8:16 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> > On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote:
> > > I'm wanting to have a rootfs that is read-only SquashFS and a appfs that
> > > is encrypted.
> > I assume you want to have a A/B appfs.
> 
> Yes, have A/B for Kernel, dtb, rootfs and appfs.

OK, as a side-node: I'd suggest storing the kernel in the rootfs, as that gets
rid of potential inconsistencies, avoids the need to reserve space in the kernel
partitions and reduces the number of build artifacts to keep track of.

> > How do you encrypt your appfs? dm-crypt or fscrypt?
> So process in factory will set everything up on eMMC the first time with:
> 
> cryptsetup luksFormat /dev/mmcblk2p1 & /dev/mmcblk2p2
> cryptsetup luksOpen /dev/mmcblk2p1 crypt_appfs1 (same thing for
> /dev/mmcblk2p2)
> mkfs.ext4 /dev/mapper/crypt_appfs1 & crypt_appfs2

So dm-crypt with luks header.

> Then in normal use just have a script that figures out which slots we are
> starting, A or B to determine with appfs partition to use and cryptsetup
> luksOpen then mount /dev/mapper.

I'd open both and only mount the active one. (see below)

> > > I know a bundle can have pre and post triggers so maybe I can use those to
> > > cryptsetup luksOpen the partition and then mount it and then RAUC can do
> > > it's
> > > normal thing ... but I've not researched that enough to know if that's the
> > > way
> > > to go so thought I'd ask for some guidance to point me in the right
> > > direction
> > > first.

There is the "pre-install" slot hook:
https://rauc.readthedocs.io/en/latest/using.html#slot-hooks

It's not appropriate for your use-case, though, as it's called after RAUC has
mounted the target slot, as that would be too late.

> > If you use dm-crypt, you can just use the device-mapper path for the slot's
> > device= propert in system.conf. That way, the encryption is transparent to
> > rauc.

> Not following how that would work since the inactive appfs would be
> "closed/encrypted".

You'd luksOpen both apps partitions during boot, before starting RAUC. 

From your other mail:
> Sorry, forgot to reply-all to last message.  So when I did my luksFormat etc.,
> I used a key-file that I created with openssl rand -base64 32 >
> luks_appfs_key. 

Hmm, I thought you'd use a TPM or kernel trusted keyrings to store the key.
Where do you store this key file, so it's not easily readable by the attacker?

> Are you telling me that if I add a key and put it in the rauc key ring in
> /etc/rauc and in my system.conf refer to my appfs by /dev/mapper name rauc
> will know what to do to "open" the inactive appfs to do the update?

No. The rauc keyring is only for checking the signature on the bundle.


> I guess I'm hung up on how the "open" will take place and how to tell rauc
> about the key to use etc.  

rauc has no special support for any specific type of block device, as it just
uses the abstraction as provided by the Linux kernel, similar to mkfs.ext4.

So anything that can be used by i.e. ext4 can be used by rauc, you only have to
setup the devices before starting rauc. This means that rauc works with HDDs,
SSDs, USB-Sticks, SD-Cards, eMMCs, NVMe, RAID, LVM, dm-verity/-crypt/-integrity
and anything else that's represented as a Linux block device, without needing
specific code for each.

In the case of block device encryption, this also avoids the need to give rauc
access to the key material. Having a service/script during boot be the only
place where the key is handled, avoids exposing it in the rest of the system,
where it could be compromised.

So my suggestion is: During boot, get the key material in your project-specific
way (TPM/HSM/OP-TEE/...) and use cryptsetup/dmsetup to create both
/dev/mapper/crypt_appfs[12] and then discard the key material from userspace, so
only the dm-crypt target keeps it alive. In rauc's system.conf, you set
device=/dev/mapper/crypt_appfs1 and /dev/mapper/crypt_appfs2 for the appfs
slots. This way, it rauc can use them as any other block device.

Regards,
Jan


_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
  2021-07-23 13:40     ` Jan Lübbe
@ 2021-07-30 13:33       ` Brian Hutchinson
  2021-07-30 14:20         ` Brian Hutchinson
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Hutchinson @ 2021-07-30 13:33 UTC (permalink / raw)
  To: Jan Lübbe; +Cc: rauc

[-- Attachment #1: Type: text/plain, Size: 7058 bytes --]

Hi Jan,


On Fri, Jul 23, 2021 at 9:40 AM Jan Lübbe <jlu@pengutronix.de> wrote:

> Hi Brian,
>
> On Thu, 2021-07-22 at 08:55 -0400, Brian Hutchinson wrote:
> > Hi Jan,
> >
> > On Thu, Jul 22, 2021 at 8:16 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> > > On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote:
> > > > I'm wanting to have a rootfs that is read-only SquashFS and a appfs
> that
> > > > is encrypted.
> > > I assume you want to have a A/B appfs.
> >
> > Yes, have A/B for Kernel, dtb, rootfs and appfs.
>
> OK, as a side-node: I'd suggest storing the kernel in the rootfs, as that
> gets
> rid of potential inconsistencies, avoids the need to reserve space in the
> kernel
> partitions and reduces the number of build artifacts to keep track of.
>
> > > How do you encrypt your appfs? dm-crypt or fscrypt?
> > So process in factory will set everything up on eMMC the first time with:
> >
> > cryptsetup luksFormat /dev/mmcblk2p1 & /dev/mmcblk2p2
> > cryptsetup luksOpen /dev/mmcblk2p1 crypt_appfs1 (same thing for
> > /dev/mmcblk2p2)
> > mkfs.ext4 /dev/mapper/crypt_appfs1 & crypt_appfs2
>
> So dm-crypt with luks header.
>
> > Then in normal use just have a script that figures out which slots we are
> > starting, A or B to determine with appfs partition to use and cryptsetup
> > luksOpen then mount /dev/mapper.
>
> I'd open both and only mount the active one. (see below)
>
> > > > I know a bundle can have pre and post triggers so maybe I can use
> those to
> > > > cryptsetup luksOpen the partition and then mount it and then RAUC
> can do
> > > > it's
> > > > normal thing ... but I've not researched that enough to know if
> that's the
> > > > way
> > > > to go so thought I'd ask for some guidance to point me in the right
> > > > direction
> > > > first.
>
> There is the "pre-install" slot hook:
> https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
>
> It's not appropriate for your use-case, though, as it's called after RAUC
> has
> mounted the target slot, as that would be too late.
>
> > > If you use dm-crypt, you can just use the device-mapper path for the
> slot's
> > > device= propert in system.conf. That way, the encryption is
> transparent to
> > > rauc.
>
> > Not following how that would work since the inactive appfs would be
> > "closed/encrypted".
>
> You'd luksOpen both apps partitions during boot, before starting RAUC.
>
> From your other mail:
> > Sorry, forgot to reply-all to last message.  So when I did my luksFormat
> etc.,
> > I used a key-file that I created with openssl rand -base64 32 >
> > luks_appfs_key.
>
> Hmm, I thought you'd use a TPM or kernel trusted keyrings to store the key.
> Where do you store this key file, so it's not easily readable by the
> attacker?
>

It's a long story, no requirement for "secure boot" only "encrypt files at
rest".  I know, I know.  I just follow schedules ;)


> > Are you telling me that if I add a key and put it in the rauc key ring in
> > /etc/rauc and in my system.conf refer to my appfs by /dev/mapper name
> rauc
> > will know what to do to "open" the inactive appfs to do the update?
>
> No. The rauc keyring is only for checking the signature on the bundle.
>
>
> > I guess I'm hung up on how the "open" will take place and how to tell
> rauc
> > about the key to use etc.
>
> rauc has no special support for any specific type of block device, as it
> just
> uses the abstraction as provided by the Linux kernel, similar to mkfs.ext4.
>
> So anything that can be used by i.e. ext4 can be used by rauc, you only
> have to
> setup the devices before starting rauc. This means that rauc works with
> HDDs,
> SSDs, USB-Sticks, SD-Cards, eMMCs, NVMe, RAID, LVM,
> dm-verity/-crypt/-integrity
> and anything else that's represented as a Linux block device, without
> needing
> specific code for each.
>
> In the case of block device encryption, this also avoids the need to give
> rauc
> access to the key material. Having a service/script during boot be the only
> place where the key is handled, avoids exposing it in the rest of the
> system,
> where it could be compromised.
>
> So my suggestion is: During boot, get the key material in your
> project-specific
> way (TPM/HSM/OP-TEE/...) and use cryptsetup/dmsetup to create both
> /dev/mapper/crypt_appfs[12] and then discard the key material from
> userspace, so
> only the dm-crypt target keeps it alive. In rauc's system.conf, you set
> device=/dev/mapper/crypt_appfs1 and /dev/mapper/crypt_appfs2 for the appfs
> slots. This way, it rauc can use them as any other block device.
>
> So here is the test I did ... that didn't work.

I nfs booted my board.  rauc thinks I've booted from slot A so it's going
to try to update slot B.

I do:

cryptsetup luksFormat /dev/mmcblk2p2 /boot/luks_appfs_key
cryptsetup luksOpen /dev/mmcblk2p2 crypt_appfs2 --key-file
/boot/luks_appfs_key
mkfs.ext4 /dev/mapper/crypt_appfs2

My /etc/rauc/system.conf looks like:

[system]
compatible=MyBoard
bootloader=uboot

[keyring]
path=/etc/rauc/ca.cert.pem

[slot.kernel.0]
device=/dev/mmcblk2gp0p1
type=vfat
parent=rootfs.0

[slot.kernel.1]
device=/dev/mmcblk2gp1p1
type=vfat
parent=rootfs.1

[slot.rootfs.0]
device=/dev/mmcblk2gp1p2
type=ext4
bootname=A

[slot.rootfs.1]
device=/dev/mmcblk2gp1p2
type=ext4
bootname=B

[slot.appfs.0]
device=/dev/mmcblk2p1
type=ext4
parent=rootfs.0

[slot.appfs.1]
device=/dev/mapper/crypt_appfs2
type=ext4
parent=rootfs.1

So at this point, /dev/mapper/crypt_appfs2 is open but not mounted.

I have my bundle scp to /tmp so I try to install it and get:

installing
 0% Installing
 0% Determining slot states
20% Determining slot states done.
20% Checking bundle
20% Verifying signature
40% Verifying signature done.
40% Checking bundle done.
40% Checking manifest contents
60% Checking manifest contents done.
60% Determining target install group
80% Determining target install group done.
80% Updating slots
80% Checking slot kernel.1
83% Checking slot kernel.1 done.
83% Copying image to kernel.1
86% Copying image to kernel.1 done.
86% Checking slot rootfs.1
90% Checking slot rootfs.1 done.
90% Copying image to rootfs.1
[ 1901.504350] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered data
mode. Opts: (null)
93% Copying image to rootfs.1 done.
[ 1927.854400] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered data
mode. Opts: (null)
93% Checking slot appfs.1
96% Checking slot appfs.1 done.
96% Copying image to appfs.1
100% Copying image to appfs.1 failed.
100% Updating slots failed.
100% Installing failed.
LastError: Installation error: Failed updating slot appfs.1: failed to run
mkfs.ext4: Child process exited with code 1
Installing `/tmp/./update-myboard.raucb` failed

But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and the
filesystem is fine.

Looks like I'm missing something still.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 13467 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
  2021-07-30 13:33       ` Brian Hutchinson
@ 2021-07-30 14:20         ` Brian Hutchinson
  2021-07-30 16:29           ` Jan Lübbe
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Hutchinson @ 2021-07-30 14:20 UTC (permalink / raw)
  To: Jan Lübbe; +Cc: rauc

[-- Attachment #1: Type: text/plain, Size: 8170 bytes --]

Hi all, update

On Fri, Jul 30, 2021 at 9:33 AM Brian Hutchinson <b.hutchman@gmail.com>
wrote:

> Hi Jan,
>
>
> On Fri, Jul 23, 2021 at 9:40 AM Jan Lübbe <jlu@pengutronix.de> wrote:
>
>> Hi Brian,
>>
>> On Thu, 2021-07-22 at 08:55 -0400, Brian Hutchinson wrote:
>> > Hi Jan,
>> >
>> > On Thu, Jul 22, 2021 at 8:16 AM Jan Lübbe <jlu@pengutronix.de> wrote:
>> > > On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote:
>> > > > I'm wanting to have a rootfs that is read-only SquashFS and a appfs
>> that
>> > > > is encrypted.
>> > > I assume you want to have a A/B appfs.
>> >
>> > Yes, have A/B for Kernel, dtb, rootfs and appfs.
>>
>> OK, as a side-node: I'd suggest storing the kernel in the rootfs, as that
>> gets
>> rid of potential inconsistencies, avoids the need to reserve space in the
>> kernel
>> partitions and reduces the number of build artifacts to keep track of.
>>
>> > > How do you encrypt your appfs? dm-crypt or fscrypt?
>> > So process in factory will set everything up on eMMC the first time
>> with:
>> >
>> > cryptsetup luksFormat /dev/mmcblk2p1 & /dev/mmcblk2p2
>> > cryptsetup luksOpen /dev/mmcblk2p1 crypt_appfs1 (same thing for
>> > /dev/mmcblk2p2)
>> > mkfs.ext4 /dev/mapper/crypt_appfs1 & crypt_appfs2
>>
>> So dm-crypt with luks header.
>>
>> > Then in normal use just have a script that figures out which slots we
>> are
>> > starting, A or B to determine with appfs partition to use and cryptsetup
>> > luksOpen then mount /dev/mapper.
>>
>> I'd open both and only mount the active one. (see below)
>>
>> > > > I know a bundle can have pre and post triggers so maybe I can use
>> those to
>> > > > cryptsetup luksOpen the partition and then mount it and then RAUC
>> can do
>> > > > it's
>> > > > normal thing ... but I've not researched that enough to know if
>> that's the
>> > > > way
>> > > > to go so thought I'd ask for some guidance to point me in the right
>> > > > direction
>> > > > first.
>>
>> There is the "pre-install" slot hook:
>> https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
>>
>> It's not appropriate for your use-case, though, as it's called after RAUC
>> has
>> mounted the target slot, as that would be too late.
>>
>> > > If you use dm-crypt, you can just use the device-mapper path for the
>> slot's
>> > > device= propert in system.conf. That way, the encryption is
>> transparent to
>> > > rauc.
>>
>> > Not following how that would work since the inactive appfs would be
>> > "closed/encrypted".
>>
>> You'd luksOpen both apps partitions during boot, before starting RAUC.
>>
>> From your other mail:
>> > Sorry, forgot to reply-all to last message.  So when I did my
>> luksFormat etc.,
>> > I used a key-file that I created with openssl rand -base64 32 >
>> > luks_appfs_key.
>>
>> Hmm, I thought you'd use a TPM or kernel trusted keyrings to store the
>> key.
>> Where do you store this key file, so it's not easily readable by the
>> attacker?
>>
>
> It's a long story, no requirement for "secure boot" only "encrypt files at
> rest".  I know, I know.  I just follow schedules ;)
>
>
>> > Are you telling me that if I add a key and put it in the rauc key ring
>> in
>> > /etc/rauc and in my system.conf refer to my appfs by /dev/mapper name
>> rauc
>> > will know what to do to "open" the inactive appfs to do the update?
>>
>> No. The rauc keyring is only for checking the signature on the bundle.
>>
>>
>> > I guess I'm hung up on how the "open" will take place and how to tell
>> rauc
>> > about the key to use etc.
>>
>> rauc has no special support for any specific type of block device, as it
>> just
>> uses the abstraction as provided by the Linux kernel, similar to
>> mkfs.ext4.
>>
>> So anything that can be used by i.e. ext4 can be used by rauc, you only
>> have to
>> setup the devices before starting rauc. This means that rauc works with
>> HDDs,
>> SSDs, USB-Sticks, SD-Cards, eMMCs, NVMe, RAID, LVM,
>> dm-verity/-crypt/-integrity
>> and anything else that's represented as a Linux block device, without
>> needing
>> specific code for each.
>>
>> In the case of block device encryption, this also avoids the need to give
>> rauc
>> access to the key material. Having a service/script during boot be the
>> only
>> place where the key is handled, avoids exposing it in the rest of the
>> system,
>> where it could be compromised.
>>
>> So my suggestion is: During boot, get the key material in your
>> project-specific
>> way (TPM/HSM/OP-TEE/...) and use cryptsetup/dmsetup to create both
>> /dev/mapper/crypt_appfs[12] and then discard the key material from
>> userspace, so
>> only the dm-crypt target keeps it alive. In rauc's system.conf, you set
>> device=/dev/mapper/crypt_appfs1 and /dev/mapper/crypt_appfs2 for the appfs
>> slots. This way, it rauc can use them as any other block device.
>>
>> So here is the test I did ... that didn't work.
>
> I nfs booted my board.  rauc thinks I've booted from slot A so it's going
> to try to update slot B.
>
> I do:
>
> cryptsetup luksFormat /dev/mmcblk2p2 /boot/luks_appfs_key
> cryptsetup luksOpen /dev/mmcblk2p2 crypt_appfs2 --key-file
> /boot/luks_appfs_key
> mkfs.ext4 /dev/mapper/crypt_appfs2
>
> My /etc/rauc/system.conf looks like:
>
> [system]
> compatible=MyBoard
> bootloader=uboot
>
> [keyring]
> path=/etc/rauc/ca.cert.pem
>
> [slot.kernel.0]
> device=/dev/mmcblk2gp0p1
> type=vfat
> parent=rootfs.0
>
> [slot.kernel.1]
> device=/dev/mmcblk2gp1p1
> type=vfat
> parent=rootfs.1
>
> [slot.rootfs.0]
> device=/dev/mmcblk2gp1p2
> type=ext4
> bootname=A
>
> [slot.rootfs.1]
> device=/dev/mmcblk2gp1p2
> type=ext4
> bootname=B
>
> [slot.appfs.0]
> device=/dev/mmcblk2p1
> type=ext4
> parent=rootfs.0
>
> [slot.appfs.1]
> device=/dev/mapper/crypt_appfs2
> type=ext4
> parent=rootfs.1
>
> So at this point, /dev/mapper/crypt_appfs2 is open but not mounted.
>
> I have my bundle scp to /tmp so I try to install it and get:
>
> installing
>  0% Installing
>  0% Determining slot states
> 20% Determining slot states done.
> 20% Checking bundle
> 20% Verifying signature
> 40% Verifying signature done.
> 40% Checking bundle done.
> 40% Checking manifest contents
> 60% Checking manifest contents done.
> 60% Determining target install group
> 80% Determining target install group done.
> 80% Updating slots
> 80% Checking slot kernel.1
> 83% Checking slot kernel.1 done.
> 83% Copying image to kernel.1
> 86% Copying image to kernel.1 done.
> 86% Checking slot rootfs.1
> 90% Checking slot rootfs.1 done.
> 90% Copying image to rootfs.1
> [ 1901.504350] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered
> data mode. Opts: (null)
> 93% Copying image to rootfs.1 done.
> [ 1927.854400] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered
> data mode. Opts: (null)
> 93% Checking slot appfs.1
> 96% Checking slot appfs.1 done.
> 96% Copying image to appfs.1
> 100% Copying image to appfs.1 failed.
> 100% Updating slots failed.
> 100% Installing failed.
> LastError: Installation error: Failed updating slot appfs.1: failed to run
> mkfs.ext4: Child process exited with code 1
> Installing `/tmp/./update-myboard.raucb` failed
>
> But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and the
> filesystem is fine.
>
> Looks like I'm missing something still.
>
>
So I think my issue was because I was nfs booted.  Slot A was activated but
not booted. But it looks like maybe it was using slot A
/etc/rauc/system.conf instead of the currently running nfs instance
/etc/rauc/system.conf because what I tried before worked once I mounted
/dev/mmcblk2gp0p2 and changed that /etc/rauc/system.conf to:

[slot.appfs.1]
device=/dev/mapper/crypt_appfs2
type=ext4
parent=rootfs.1

So this brings up a question.  If I have boards out in the field and appfs
goes from plain ext4 to encrypted, I somehow need to update the currently
running /etc/rauc/system.conf file first before performing an update???
How to handle system.conf changes?

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 14197 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
  2021-07-30 14:20         ` Brian Hutchinson
@ 2021-07-30 16:29           ` Jan Lübbe
  2021-08-02 15:22             ` Brian Hutchinson
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Lübbe @ 2021-07-30 16:29 UTC (permalink / raw)
  To: Brian Hutchinson; +Cc: rauc

Hi Brian,

On Fri, 2021-07-30 at 10:20 -0400, Brian Hutchinson wrote:
> > 100% Installing failed.
> > LastError: Installation error: Failed updating slot appfs.1: failed to run
> > mkfs.ext4: Child process exited with code 1
> > Installing `/tmp/./update-myboard.raucb` failed
> > 
> > But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and the
> > filesystem is fine.
> > 
> > Looks like I'm missing something still.

Hmm, you should have more logs on the rauc service side, possible also with an
error message from mkfs.ext4.

> 
> So I think my issue was because I was nfs booted.  Slot A was activated but not
> booted. But it looks like maybe it was using slot A /etc/rauc/system.conf
> instead of the currently running nfs instance /etc/rauc/system.conf because what
> I tried before worked once I mounted /dev/mmcblk2gp0p2 and changed that
> /etc/rauc/system.conf to:

It should use /etc/rauc/system.conf from the mounted rootfs, so NFS in your
case.

>  [slot.appfs.1]
> device=/dev/mapper/crypt_appfs2
> type=ext4
> parent=rootfs.1
> 
> So this brings up a question.  If I have boards out in the field and appfs goes
> from plain ext4 to encrypted, I somehow need to update the currently running
> /etc/rauc/system.conf file first before performing an update???  How to handle
> system.conf changes?

The system.conf contents should describe the details of the system than don't
change during updates. Generally, partitioning changes are not possible in an
atomic A/B way, so those are not really in scope for RAUC. :/

Getting such a migration correct in the field is difficult. Something you could
use, though.

The device= properties will follow symlinks. So you could handle the switch
between unencrypted and encrypted in a script before starting the rauc service
and before mounting the current appfs.

For both sides, you'd check if it already contains a luks header. If not, it's
an old version which doesn't support encryption yet, so you link /dev/mmcblk...
to /dev/appfs[12].
If if already contains that header, attach the crypt device. The setup the
/dev/appfs[12] link to /dev/mapper/crypt_appfs[12]).

The system.conf would then point to device=/dev/appfs[12].

Then add a pre-install handler:
https://rauc.readthedocs.io/en/latest/using.html#system-based-customization-handlers
It can check if the target slot link still points to the unencrypted device. In
that case, it can setup the crypt device and change the link. RAUC should(*)
then follow the updated link to the encrypted device when installing.

Hope that helps... :)

You can also join us in #rauc on libera.chat or via matrix.org.

Jan

(*) I'm not 100% sure right now when the symlink resolution happens. So you
should check the source. :)
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
  2021-07-30 16:29           ` Jan Lübbe
@ 2021-08-02 15:22             ` Brian Hutchinson
  2021-08-02 15:39               ` Jan Lübbe
  0 siblings, 1 reply; 9+ messages in thread
From: Brian Hutchinson @ 2021-08-02 15:22 UTC (permalink / raw)
  To: Jan Lübbe, rauc

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

On Fri, Jul 30, 2021 at 12:29 PM Jan Lübbe <jlu@pengutronix.de> wrote:

> Hi Brian,
>
> On Fri, 2021-07-30 at 10:20 -0400, Brian Hutchinson wrote:
> > > 100% Installing failed.
> > > LastError: Installation error: Failed updating slot appfs.1: failed to
> run
> > > mkfs.ext4: Child process exited with code 1
> > > Installing `/tmp/./update-myboard.raucb` failed
> > >
> > > But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and
> the
> > > filesystem is fine.
> > >
> > > Looks like I'm missing something still.
>
> Hmm, you should have more logs on the rauc service side, possible also
> with an
> error message from mkfs.ext4.
>
> >
> > So I think my issue was because I was nfs booted.  Slot A was activated
> but not
> > booted. But it looks like maybe it was using slot A /etc/rauc/system.conf
> > instead of the currently running nfs instance /etc/rauc/system.conf
> because what
> > I tried before worked once I mounted /dev/mmcblk2gp0p2 and changed that
> > /etc/rauc/system.conf to:
>
> It should use /etc/rauc/system.conf from the mounted rootfs, so NFS in your
> case.
>
> >  [slot.appfs.1]
> > device=/dev/mapper/crypt_appfs2
> > type=ext4
> > parent=rootfs.1
> >
> > So this brings up a question.  If I have boards out in the field and
> appfs goes
> > from plain ext4 to encrypted, I somehow need to update the currently
> running
> > /etc/rauc/system.conf file first before performing an update???  How to
> handle
> > system.conf changes?
>
> The system.conf contents should describe the details of the system than
> don't
> change during updates. Generally, partitioning changes are not possible in
> an
> atomic A/B way, so those are not really in scope for RAUC. :/
>
> Getting such a migration correct in the field is difficult. Something you
> could
> use, though.
>
> The device= properties will follow symlinks. So you could handle the switch
> between unencrypted and encrypted in a script before starting the rauc
> service
> and before mounting the current appfs.
>
> For both sides, you'd check if it already contains a luks header. If not,
> it's
> an old version which doesn't support encryption yet, so you link
> /dev/mmcblk...
> to /dev/appfs[12].
> If if already contains that header, attach the crypt device. The setup the
> /dev/appfs[12] link to /dev/mapper/crypt_appfs[12]).
>
> The system.conf would then point to device=/dev/appfs[12].
>
> Then add a pre-install handler:
>
> https://rauc.readthedocs.io/en/latest/using.html#system-based-customization-handlers
> It can check if the target slot link still points to the unencrypted
> device. In
> that case, it can setup the crypt device and change the link. RAUC
> should(*)
> then follow the updated link to the encrypted device when installing.
>
> Hope that helps... :)
>
>
Hi Jan,

Yes!  Thanks.

Now my problem is I have a very small 32M NOR flash and I have a 11M
SquashFS rootfs based off core-image-minimal.  I added packagegroup-luks
and it blew size up to 47M.  I then just tried to CORE_IMAGE_EXTRA_INSTALL
+= "cryptsetup" and that was still a 35M rootfs so now I'm stumped trying
to figure out if it's possible to get encryption support in my NOR flash
image we boot from :(

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 4648 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it
  2021-08-02 15:22             ` Brian Hutchinson
@ 2021-08-02 15:39               ` Jan Lübbe
  0 siblings, 0 replies; 9+ messages in thread
From: Jan Lübbe @ 2021-08-02 15:39 UTC (permalink / raw)
  To: Brian Hutchinson, rauc

On Mon, 2021-08-02 at 11:22 -0400, Brian Hutchinson wrote:
> Hi Jan,
> 
> Yes!  Thanks.

Good. :)

> Now my problem is I have a very small 32M NOR flash and I have a 11M SquashFS
> rootfs based off core-image-minimal.  I added packagegroup-luks and it blew size
> up to 47M.  I then just tried to CORE_IMAGE_EXTRA_INSTALL += "cryptsetup" and
> that was still a 35M rootfs so now I'm stumped trying to figure out if it's
> possible to get encryption support in my NOR flash image we boot from :(

This seems to relate more to OE/Yocto, than to rauc, so perhaps #oe/#yocto is a
better place to ask this. :)

I don't remember sizes for cryptsetup right now, but 35MB seems large. The
cryptsetup recipe has many PACKAGECONFIGs, so you might want to limit those to
the ones you actually need.

You can find much more ideas and analysis methods in the docs:
https://docs.yoctoproject.org/singleindex.html#building-a-tiny-system

Regards,
Jan
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


_______________________________________________
RAUC mailing list

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-08-02 15:39 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-22 12:11 [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it Brian Hutchinson
2021-07-22 12:16 ` Jan Lübbe
     [not found]   ` <CAFZh4h8Hd+sBBNz9m1ZJvnHEg9hsL4R19cmKJ21Y9Asiss2B5Q@mail.gmail.com>
2021-07-23 12:45     ` Brian Hutchinson
2021-07-23 13:40     ` Jan Lübbe
2021-07-30 13:33       ` Brian Hutchinson
2021-07-30 14:20         ` Brian Hutchinson
2021-07-30 16:29           ` Jan Lübbe
2021-08-02 15:22             ` Brian Hutchinson
2021-08-02 15:39               ` Jan Lübbe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox