[isar-cip-core][QUESTION] initramfs-overlay-hook: tmpFS for overlay storage

[isar-cip-core][QUESTION] initramfs-overlay-hook: tmpFS for overlay storage

[d.kauschke154]

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

Hello all,

I have some questions regarding the use of the initramfs-overlay-hook feature in CIP Core:
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-hook_0.3.bb

Currently, I’m using the default behavior where the overlay’s upper directory is located on a separate, persistent /var partition.
An wic example setup can be found here:
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/wic/bbb-efibootguard.wks.in

At runtime, /etc/fstab includes an entry:

overlay on /etc type overlay (rw,relatime,lowerdir=/root/etc,upperdir=/root/var/local/etc,workdir=/root/var/local/.etc-atomic,uuid=on)

In this setup, the root filesystem is mounted read-only, and directories like /etc are made writable via an overlay.

This works well from a functional perspective, but due to the use of persistent storage for the upper and work directories (on /var),
all runtime modifications are retained across reboots.
For example:
/etc/machine-id can be modified as expected,
but also a file like /etc/systemd/system/attacker.service could be dropped during runtime by someone with physical access to the flash of the device.
These files would then persist across reboots, undermining runtime integrity.

Questions:
1) Is there an existing way to configure initramfs-overlay-hook to use a volatile overlay backed by tmpFS for the upper directories?
2) If not, would it be feasible or acceptable to extend the recipe to optionally support such a mode?
3) Are there known reasons why a tmpFS for overlay storage was not implemented yet?

The goal is to ensure that the system always boots into a clean and controlled state,
without retaining any changes made during runtime — for improved security and integrity.

Thank you for your time and expertise.

Best regards,
David

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

Re: [isar-cip-core][QUESTION] initramfs-overlay-hook: tmpFS for overlay storage

[Jan Kiszka]

Hi David,

oops, I think no one replied to this question back then, right? Was the
topic resolved in the meantime, or is it still open?

On 20.05.25 07:53, d.kauschke154@googlemail.com wrote:
> Hello all,
>  
> I have some questions regarding the use of the initramfs-overlay-hook
> feature in CIP Core:
> https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/
> recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-hook_0.3.bb
> <https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/
> recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-hook_0.3.bb>
>  
> Currently, I’m using the default behavior where the overlay’s upper
> directory is located on a separate, persistent /var partition.
> An wic example setup can be found here:
> https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/wic/
> bbb-efibootguard.wks.in <https://gitlab.com/cip-project/cip-core/isar-
> cip-core/-/blob/master/wic/bbb-efibootguard.wks.in>
>  
> At runtime, /etc/fstab includes an entry:
>  
> overlay on /etc type overlay (rw,relatime,lowerdir=/root/etc,upperdir=/
> root/var/local/etc,workdir=/root/var/local/.etc-atomic,uuid=on)
>  
> In this setup, the root filesystem is mounted read-only, and directories
> like /etc are made writable via an overlay.
>  
> This works well from a functional perspective, but due to the use of
> persistent storage for the upper and work directories (on /var),
> all runtime modifications are retained across reboots.
> For example:
> /etc/machine-id can be modified as expected,
> but also a file like /etc/systemd/system/attacker.service could be
> dropped during runtime by someone with physical access to the flash of
> the device.
> These files would then persist across reboots, undermining runtime
> integrity.
>  
> Questions:
> 1) Is there an existing way to configure initramfs-overlay-hook to use a
> volatile overlay backed by tmpFS for the upper directories?
> 2) If not, would it be feasible or acceptable to extend the recipe to
> optionally support such a mode?
> 3) Are there known reasons why a tmpFS for overlay storage was not
> implemented yet?

Not sure if there is anything preventing to specify some folder on an
existing tmpfs mountpoint as backing. With trixie, /tmp should be
available for that, e.g.

>  
> The goal is to ensure that the system always boots into a clean and
> controlled state,
> without retaining any changes made during runtime — for improved
> security and integrity.
>  
> Thank you for your time and expertise.
>  
> Best regards,
> David

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: [isar-cip-core][QUESTION] initramfs-overlay-hook: tmpFS for overlay storage

[Quirin Gylstorff]

On 8/24/25 12:16, Jan Kiszka wrote:
> Hi David,
> 
> oops, I think no one replied to this question back then, right? Was the
> topic resolved in the meantime, or is it still open?
> 
> On 20.05.25 07:53, d.kauschke154@googlemail.com wrote:
>> Hello all,
>>   
>> I have some questions regarding the use of the initramfs-overlay-hook
>> feature in CIP Core:
>> https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/
>> recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-hook_0.3.bb
>> <https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/
>> recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-hook_0.3.bb>
>>   
>> Currently, I’m using the default behavior where the overlay’s upper
>> directory is located on a separate, persistent /var partition.
>> An wic example setup can be found here:
>> https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/wic/
>> bbb-efibootguard.wks.in <https://gitlab.com/cip-project/cip-core/isar-
>> cip-core/-/blob/master/wic/bbb-efibootguard.wks.in>
>>   
>> At runtime, /etc/fstab includes an entry:
>>   
>> overlay on /etc type overlay (rw,relatime,lowerdir=/root/etc,upperdir=/
>> root/var/local/etc,workdir=/root/var/local/.etc-atomic,uuid=on)
>>   
>> In this setup, the root filesystem is mounted read-only, and directories
>> like /etc are made writable via an overlay.
>>   
>> This works well from a functional perspective, but due to the use of
>> persistent storage for the upper and work directories (on /var),
>> all runtime modifications are retained across reboots.
>> For example:
>> /etc/machine-id can be modified as expected,
>> but also a file like /etc/systemd/system/attacker.service could be
>> dropped during runtime by someone with physical access to the flash of
>> the device.
>> These files would then persist across reboots, undermining runtime
>> integrity.
>>   
>> Questions:
>> 1) Is there an existing way to configure initramfs-overlay-hook to use a
>> volatile overlay backed by tmpFS for the upper directories?
>> 2) If not, would it be feasible or acceptable to extend the recipe to
>> optionally support such a mode?
>> 3) Are there known reasons why a tmpFS for overlay storage was not
>> implemented yet?
> 
> Not sure if there is anything preventing to specify some folder on an
> existing tmpfs mountpoint as backing. With trixie, /tmp should be
> available for that, e.g.
> 

You can simple set the variable INITRAMFS_OVERLAY_STORAGE_PATH in 
configuration(distro, kas or machine ):

```
INITRAMFS_OVERLAY_STORAGE_PATH = "/tmp"
```

Quirin


>>   
>> The goal is to ensure that the system always boots into a clean and
>> controlled state,
>> without retaining any changes made during runtime — for improved
>> security and integrity.
>>   
>> Thank you for your time and expertise.
>>   
>> Best regards,
>> David
> 
> Jan
> 

Re: [cip-dev] [isar-cip-core][QUESTION] initramfs-overlay-hook: tmpFS for overlay storage

[Heinisch, Alexander]

On Thu, 2025-08-28 at 12:48 +0200, Quirin Gylstorff via lists.cip-
project.org wrote:
>
>
> On 8/24/25 12:16, Jan Kiszka wrote:
> > Hi David,
> >
> > oops, I think no one replied to this question back then, right? Was
> > the
> > topic resolved in the meantime, or is it still open?
> >
> > On 20.05.25 07:53, d.kauschke154@googlemail.com wrote:
> > > Hello all,
> > >
> > > I have some questions regarding the use of the initramfs-overlay-
> > > hook
> > > feature in CIP Core:
> > > https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/
> > > recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-
> > > hook_0.3.bb
> > > <
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > gitlab.com%2Fcip-project%2Fcip-core%2Fisar-cip-core%2F-
> > > %2Fblob%2Fmaster%2F&data=05%7C02%7Calexander.heinisch%40siemens.c
> > > om%7C3d4115b1b87f46e1d66308dde6206f60%7C38ae3bcd95794fd4addab42e1
> > > 495d55a%7C1%7C0%7C638919749159669284%7CUnknown%7CTWFpbGZsb3d8eyJF
> > > bXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> > > WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mzwlxx4Rq1VxC2WEUisczu
> > > Ai2%2FW6gWszsgVI2ttChKs%3D&reserved=0
> > > recipes-initramfs/initramfs-overlay-hook/initramfs-overlay-
> > > hook_0.3.bb>
> > >
> > > Currently, I’m using the default behavior where the overlay’s
> > > upper
> > > directory is located on a separate, persistent /var partition.
> > > An wic example setup can be found here:
> > > https://gitlab.com/cip-project/cip-core/isar-cip-core/-/blob/master/wic/
> > > bbb-efibootguard.wks.in
> > > <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%25
> > > 2Fgitlab.com%2Fcip-project%2Fcip-core%2Fisar-
> > > &data=05%7C02%7Calexander.heinisch%40siemens.com%7C3d4115b1b87f46
> > > e1d66308dde6206f60%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6
> > > 38919749159690094%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> > > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
> > > D%3D%7C0%7C%7C%7C&sdata=Cj%2BP8HzetDwQEKir6U048a3nt84DJRL%2FxTmQc
> > > 5VbFeM%3D&reserved=0
> > > cip-core/-/blob/master/wic/bbb-efibootguard.wks.in>
> > >
> > > At runtime, /etc/fstab includes an entry:
> > >
> > > overlay on /etc type overlay
> > > (rw,relatime,lowerdir=/root/etc,upperdir=/
> > > root/var/local/etc,workdir=/root/var/local/.etc-atomic,uuid=on)
> > >
> > > In this setup, the root filesystem is mounted read-only, and
> > > directories
> > > like /etc are made writable via an overlay.
> > >
> > > This works well from a functional perspective, but due to the use
> > > of
> > > persistent storage for the upper and work directories (on /var),
> > > all runtime modifications are retained across reboots.
> > > For example:
> > > /etc/machine-id can be modified as expected,
> > > but also a file like /etc/systemd/system/attacker.service could
> > > be
> > > dropped during runtime by someone with physical access to the
> > > flash of
> > > the device.
> > > These files would then persist across reboots, undermining
> > > runtime
> > > integrity.
> > >
> > > Questions:
> > > 1) Is there an existing way to configure initramfs-overlay-hook
> > > to use a
> > > volatile overlay backed by tmpFS for the upper directories?
> > > 2) If not, would it be feasible or acceptable to extend the
> > > recipe to
> > > optionally support such a mode?
> > > 3) Are there known reasons why a tmpFS for overlay storage was
> > > not
> > > implemented yet?

As Jan and Quirin mentioned, (at least on trixie) it's just a matter of
configuration. Nevertheless, not having persistent /etc can have side
effects like e.g. systemd's /etc/machine-id, that needs special
treatment in case you don't want to have first-boot semantics on every
restart.

We had a discussion back then on ro /etc on this RFC [1].
We use a similar patch series downstream, build images with only /var
rw and all the rest ro.
This approach was mainly driven due to the points you mentioned above
as well as to prevent local changes that might require a merge on
updates.

Since systemd itself tries to enforce ro /usr and rw /etc we decided
not to integrate it in isar-cip-core as this could make long time
maintenance pretty hard. A discussion with upstream systemd has still
not happened yet. :-(

[1]
https://lists.cip-project.org/g/cip-dev/message/19275?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2CAlexander+Heinisch%2C20%2C2%2C0%2C113913313

BR Alexander

> >
> > Not sure if there is anything preventing to specify some folder on
> > an
> > existing tmpfs mountpoint as backing. With trixie, /tmp should be
> > available for that, e.g.
> >
>
> You can simple set the variable INITRAMFS_OVERLAY_STORAGE_PATH in
> configuration(distro, kas or machine ):
>
> ```
> INITRAMFS_OVERLAY_STORAGE_PATH = "/tmp"
> ```
>
> Quirin
>
>
> > >
> > > The goal is to ensure that the system always boots into a clean
> > > and
> > > controlled state,
> > > without retaining any changes made during runtime — for improved
> > > security and integrity.
> > >
> > > Thank you for your time and expertise.
> > >
> > > Best regards,
> > > David
> >
> > Jan
> >
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#19979):
> https://lists.cip-project.org/g/cip-dev/message/19979
> Mute This Topic: https://lists.cip-project.org/mt/113206778/8886423
> Group Owner: cip-dev+owner@lists.cip-project.org
> Unsubscribe:
> https://lists.cip-project.org/g/cip-dev/unsub [alexander.heinisch@siemens.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
>

--
Alexander Heinisch
Siemens AG
http://www.siemens.com/

Re: [isar-cip-core][QUESTION] initramfs-overlay-hook: tmpFS for overlay storage

[david.kauschke.ext]

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

Thank you for your help Alexander, Jan and Quirin!

Topic can be closed.

After discussion and your informations, I plan to switch to this approach:

1) Use /var as the overlay storage path and encrypt the /var partition.
2) Symlink /home to /var/home, so the only persistent partition is /var (following the move-homedir-var recipe).

This way, there’s no major divergence from the upstream CIP layer, while the encrypted /var partition addresses the security concerns.

David

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