[systemd-devel] oomd wake-up frequency
Hi! Over the past few months I've been working on improving GNOME's whole-system profiling story in the form of Sysprof¹. The primary thing I see showing up when profiling an idle system is oomd. My casual reading through the code would lead me to believe it's waking up a CPU every .15 seconds. Is there a way we could have this wake up less? My goal here is to iron out all the little things which are causing energy drain when idle. -- Christian
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Tue, Aug 22, 2023 at 8:10 PM Lennart Poettering wrote: > On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: <...> > > If attacker replaces volume with unencrypted one, and it boots without > > messing up the sealing PCRs, then probably attacker can query the TPM > > and obtain the encryption key. Despite the fact that this is not (yet) > > implemented in cryptenroll. > > Sure, if you allow unencrypted systems to boot in your OS then all > bets are off. You shouldn't do that of course. > > (in my model of mind, where automatic GPT image dissection is used the > image dissection policies are how this should be locked down, see > systemd.image-policy(7). You can confgure that via the kernel cmdline: > in systemd.image_policy=. > > In systemd there's the "systemd-pcrfs@.service" and > "systemd-pcrmachine.service" which will measure the identity of file > systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also > mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to > be an identifier of the OS instance. Wait. I was looking at this PCR. But wouldn't it be set only after the volume has been unlocked? This means that before a volume is unlocked, it cannot protect anything? Actually it may protect in case where attacker replaced the volume with another encrypted volume. But not if attacker replaced with a plain volume. Or is it measured with the *encrypted* volume key which would actually protect from volume replacement of any sort (I think) and would mostly solve my concern? I mean if somehow the LVM structure including the encrypted key(s) are measured somewhere, then such an attack should not be viable. I guess I should test whether replacing the volume with non-encrypted will work. If it works, then there might be an issue. If it does not work, then sealing with PCR 15 might be what will get me going, because replacing with an encrypted volume will definitely modify it and block decrypting of the original key. <...> > > I didn't expect the unattended server TPM2 encryption to be such a > > muddy ground. Probably because serious use cases also involve more > > infrastructure and dedicated admins, etc. > > It is certainly my intention to make this all "just work" and "default > on", even on consumer hw. Windows does it, so we should be able to do > that as well. Much needed! ♥ > Lennart > > -- > Lennart Poettering, Berlin >
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Di, 22.08.23 19:16, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > I'm concerned though about an attacker replacing the encrypted root volume > > > with a non-encrypted one. Which may result in system booting an attacker > > > controlled environment while PCRs may be in a state that allows decryption > > > of the original root volume. > > > > > > Would anything prevent the system from booting with a replaced root > > > volume? > > > > Well, when you bind your disk to the TPM then this means you place a > > TPM-encrypted key in the LUKS header. This key has to be passed to the > > right TPM to be unlocked. This means that if an attacker just has the > > disk it's hard for them to acquire the decrypted key if it lacks the > > TPM. But it also means that if an attacker wants to replace the disk > > its very hard to forge key that is locked against that specific TPM. > > If attacker replaces volume with unencrypted one, and it boots without > messing up the sealing PCRs, then probably attacker can query the TPM > and obtain the encryption key. Despite the fact that this is not (yet) > implemented in cryptenroll. Sure, if you allow unencrypted systems to boot in your OS then all bets are off. You shouldn't do that of course. (in my model of mind, where automatic GPT image dissection is used the image dissection policies are how this should be locked down, see systemd.image-policy(7). You can confgure that via the kernel cmdline: in systemd.image_policy=. In systemd there's the "systemd-pcrfs@.service" and "systemd-pcrmachine.service" which will measure the identity of file systems and of /etc/machine-id into PCR 15. (systemd-cryptsetup also mesures a derivate of the volume key to PCR 15). PCR 15 is supposed to be an identifier of the OS instance. > > It analyzes the UEFI TPM event log (which lists all measurements made > > to PCRs), tries to recognize components in it safely. And then is > > supposed to use that to generate signed PCR policies from that, based > > on a keypair stored on the local TPM, that is itself protected by one > > of its own signed PCR policies. > > > > In the long run the way I envision this we'd have two signed PCR > > policies in place: > > > > 1. A vendor supplied one that covers the UKI and its resources (this > >already pretty much exists), i.e. PCR 11. This one is pre-computed > >at build time of the OS and hence can only cover resources known at > >that time. > > > > 2. A locally maintained one on the individual system, based on a local > >key, that covers everything inherently local that is hard to > >predict from the outside (and for good measure also covers the > >vendor supplied stuff, because why not). This would then cover PCRs > >0-7, 9, 11-13, 15, i.e. everything that is reasonably stable > >locally. > > > > Alas, as mentioned this is WIP, still. > > I didn't expect the unattended server TPM2 encryption to be such a > muddy ground. Probably because serious use cases also involve more > infrastructure and dedicated admins, etc. It is certainly my intention to make this all "just work" and "default on", even on consumer hw. Windows does it, so we should be able to do that as well. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Tue, Aug 22, 2023 at 4:16 PM Lennart Poettering wrote: > > On Mo, 21.08.23 17:40, Aleksandar Kostadinov (akost...@redhat.com) wrote: > > > Hello, > > > > This is more of a user question but I didn't find any other suitable forum > > to ask. > > > > I want to install a server that should have an encrypted root but be able > > to reboot unattended. > > > > systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned > > about which PCRs to pin so that an average attacker won't be able to > > decrypt the volume having physical possession of the server. This means I'm > > not concerned about cracking the TPM chip or reading out life memory. > > > > To me it is acceptable to pin a lot of them so that adding/changing devices > > would prevent automatic decryption. Also 5 looks good about changed GPT > > partitions. > > > > I'm concerned though about an attacker replacing the encrypted root volume > > with a non-encrypted one. Which may result in system booting an attacker > > controlled environment while PCRs may be in a state that allows decryption > > of the original root volume. > > > > Would anything prevent the system from booting with a replaced root > > volume? > > Well, when you bind your disk to the TPM then this means you place a > TPM-encrypted key in the LUKS header. This key has to be passed to the > right TPM to be unlocked. This means that if an attacker just has the > disk it's hard for them to acquire the decrypted key if it lacks the > TPM. But it also means that if an attacker wants to replace the disk > its very hard to forge key that is locked against that specific TPM. If attacker replaces volume with unencrypted one, and it boots without messing up the sealing PCRs, then probably attacker can query the TPM and obtain the encryption key. Despite the fact that this is not (yet) implemented in cryptenroll. > > If it can boot in such a way, which PCRs need to be pinned to remove the > > ability to decrypt the original root volume? > > PCR pinning is a science of its own, due to the "brittleness" of > measurements, if you update firmware, boot loader, … > > So you can bind things to a bunch of PCRs, but that means you simply > cannot make changes to things anymore from that point on, and never > allow the components to update. That's quite often not what you want > in a secure system though: software has bugs after all, and *must* be > regularly updated. For my use case the idea is that sometimes I can update things while physically with the server. For simple software updates, I hope PCRs could be predicted. > I am currently working on a mechanism to deal with this brittleness, > here in this git branch: > > https://github.com/poettering/systemd/commits/pcrlock Will check it out! > It analyzes the UEFI TPM event log (which lists all measurements made > to PCRs), tries to recognize components in it safely. And then is > supposed to use that to generate signed PCR policies from that, based > on a keypair stored on the local TPM, that is itself protected by one > of its own signed PCR policies. > > In the long run the way I envision this we'd have two signed PCR > policies in place: > > 1. A vendor supplied one that covers the UKI and its resources (this >already pretty much exists), i.e. PCR 11. This one is pre-computed >at build time of the OS and hence can only cover resources known at >that time. > > 2. A locally maintained one on the individual system, based on a local >key, that covers everything inherently local that is hard to >predict from the outside (and for good measure also covers the >vendor supplied stuff, because why not). This would then cover PCRs >0-7, 9, 11-13, 15, i.e. everything that is reasonably stable >locally. > > Alas, as mentioned this is WIP, still. I didn't expect the unattended server TPM2 encryption to be such a muddy ground. Probably because serious use cases also involve more infrastructure and dedicated admins, etc. > Lennart > > -- > Lennart Poettering, Berlin
[systemd-devel] Unable to login with /home marked as nofail (Issue #28890)
Hello, I have a mobile phone with /home on an encrypted sdcard. I am trying to make sure that the phone will boot into a usable state regardless of whether /home is mounted or not. Reasons that it might not be mounted include some type of sdcard failure/corruption, or the user removing the card while powered off. The underlying / has a /home populated with a default user as a fallback in case /home is not mounted. See https://github.com/systemd/systemd/issues/28890 for further. In that issue it was stated > But of course, a user login session will still pull in the home dir of that user. Which is enforce programmatically in logind. But it's really the only thing that makes sense. Allowing the user to log in without their home dir is a very weird idea I'd argue. I cannot see how that would ever make sense? If the answer to that is not obvious from the first paragraph, I shall expound. This is not about having all of my files when I log in. It is about being able to use a thing that does not have a keyboard or mouse under as many circumstances as possible. I enjoy troubleshooting, that is why I'm here, but out on the street with the sun shining down is not a circumstance where I look forward to doing that. As it stands now, the device will not boot into a usable, or even troubleshootable, state if the sdcard is removed. It is like not being able to use your car because your phone is not plugged in. Does that make any sense? I considered creating a service to do some hackery at boot, but I was looking for a straight forward way to implement a fallback mechanism. Certainly I am not the only person who will desire a robust phone. This is not such a far out use case. I think the only reason that it has not come up yet is because systemd on phones is rather new and not many people have had to deal with a failed sdcard that puts their system into an unusable state. I mean unusable for no real reason. Sure many people have / on a failed sdcard, but that is a different story. It is also a different story when you don't have a keyboard available to log into a console for the simple task of commenting out a line in fstab, which should arguably not be necessary. It seems probably a more acceptable solution would be to create another user and mount my home under /home/me and have /home/failsafe part of /. What I have not worked out there is how to decide which user to login. Is it possible to have deps on override files? For instance, If there is a phosh(phone shell) override to run under my uid. Can applying the override depend on some condition? Something to consider is that the default user, me, is logged in automatically at boot. There is no display manager prompting for a user login, only a password protected lock screen. This is by necessity so that when a new call or message comes in there is a userspace app running to trigger a notification. It also seems that removing the nofail option would be the preferable way to do this, as it would allow visibility of the missing mount. But, that looks like a black hole as what is desired is something like a rescue target that has gui capability. graphical.target both Requires=multi-user.target and Conflicts=rescue.target multi-user.target Requires=basic.target, which Requires=`everything in fstab` Is there a way around this? I don't have a lot of confidence in overrides at this point, and this all looks like a rabbit hole leading to a programmatically implicit dependency. -Kyle Evans
Re: [systemd-devel] udev remove event no longer contains ID_VENDOR_ID/ID_MODEL_ID
On Thu, Aug 17, 2023 at 11:09 AM Matt Turner wrote: > > Hello, > > I'm working on updating ChromeOS's ancient udev-225 + 24 patches to > udev-249.9. > > In the course of testing, we discovered that udev remove events no > longer contain ID_VENDOR_ID or ID_MODEL_ID. Apparently this change > happened sometime between v225 and v239 (it was noticed during an > earlier attempt to update udev to 239). Someone questioned whether > this was an intentional change or a bug, and I suspect it's > intentional and requires some changes to ChromeOS. > > I searched but didn't find anything in git log v225..v239, but I > easily could have missed something "obvious" in ~15k commits. > > Before I bisect to find where the change happened, does anyone happen > to remember offhand? > > Thanks, > Matt FWIW, we discovered that the vendor/model/revision IDs are also available in the PRODUCT= variable (in both v225 and v249) so we've switched to using that.
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Mo, 21.08.23 19:56, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Thanks, this is what I was also considering the feasibility of. And whether > it made sense to begin with. Any idea how can this be done with systemd? > > In man I read: > > > Note that currently when enrolling a new key of one of the five > > supported types listed above, it is required to first provide a > > passphrase, a recovery key or a FIDO2 token. It's currently not > > supported to unlock a device with a TPM2/PKCS#11 key in order to > enroll > > a new TPM2/PKCS#11 key. Thus, if in future key roll-over is desired > > So I wonder if systemd already does that, or is it just an artificial > limitation? Would be wonderful if it already did so. It's just that noone implemented this. The unlocking code paths via cryptsetup and in cryptenroll are quite different, which doesn't make this trivial. But pacthes welcome. Generally, I am very much of the opinion that we shouldn't change the disk whenever PCRs change. Instead we should use signed PCR policies to accomodate for "clean" PCR changes (as mentioned in the other mail in this thread), i.e. simply sign a new PCR policy if we learn about a new "golden" PCR state we want to permit. This is much more robust and scales better. Moreover, it makes it easy to invalidate old golden states, by implicitly binding things to an nvindex counter object in the TPM at the same time. Such rollback protection is kinda crucial I am sure to guarantee security of non-interactive systems. > P.S. Also another thing I was considering was that if I did this > "extension", then I'm not sure how to then properly setup the sealing. But > maybe with the signed PCRs support it can work as PCRs don't need to be in > the expected state at configuration time. But also I want to do with as > little modifications from defaults as possible. If I have to rewrite the > whole thing, it will be hard but also I don't want to risk making mistakes > that original scripts already avoid. Neither for the literla PCR policies nor for the signed PCR policies the PCRs actailly need to be in the state we expected states when enrolling. Support for the former was recently added upstream. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] systemd-cryptenroll with TPM2
On Mo, 21.08.23 17:40, Aleksandar Kostadinov (akost...@redhat.com) wrote: > Hello, > > This is more of a user question but I didn't find any other suitable forum > to ask. > > I want to install a server that should have an encrypted root but be able > to reboot unattended. > > systemd-cryptenroll with TPM2 looks like a viable option. I'm concerned > about which PCRs to pin so that an average attacker won't be able to > decrypt the volume having physical possession of the server. This means I'm > not concerned about cracking the TPM chip or reading out life memory. > > To me it is acceptable to pin a lot of them so that adding/changing devices > would prevent automatic decryption. Also 5 looks good about changed GPT > partitions. > > I'm concerned though about an attacker replacing the encrypted root volume > with a non-encrypted one. Which may result in system booting an attacker > controlled environment while PCRs may be in a state that allows decryption > of the original root volume. > > Would anything prevent the system from booting with a replaced root > volume? Well, when you bind your disk to the TPM then this means you place a TPM-encrypted key in the LUKS header. This key has to be passed to the right TPM to be unlocked. This means that if an attacker just has the disk it's hard for them to acquire the decrypted key if it lacks the TPM. But it also means that if an attacker wants to replace the disk its very hard to forge key that is locked against that specific TPM. > If it can boot in such a way, which PCRs need to be pinned to remove the > ability to decrypt the original root volume? PCR pinning is a science of its own, due to the "brittleness" of measurements, if you update firmware, boot loader, … So you can bind things to a bunch of PCRs, but that means you simply cannot make changes to things anymore from that point on, and never allow the components to update. That's quite often not what you want in a secure system though: software has bugs after all, and *must* be regularly updated. I am currently working on a mechanism to deal with this brittleness, here in this git branch: https://github.com/poettering/systemd/commits/pcrlock It analyzes the UEFI TPM event log (which lists all measurements made to PCRs), tries to recognize components in it safely. And then is supposed to use that to generate signed PCR policies from that, based on a keypair stored on the local TPM, that is itself protected by one of its own signed PCR policies. In the long run the way I envision this we'd have two signed PCR policies in place: 1. A vendor supplied one that covers the UKI and its resources (this already pretty much exists), i.e. PCR 11. This one is pre-computed at build time of the OS and hence can only cover resources known at that time. 2. A locally maintained one on the individual system, based on a local key, that covers everything inherently local that is hard to predict from the outside (and for good measure also covers the vendor supplied stuff, because why not). This would then cover PCRs 0-7, 9, 11-13, 15, i.e. everything that is reasonably stable locally. Alas, as mentioned this is WIP, still. Lennart -- Lennart Poettering, Berlin
