<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 3:33 PM Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 3:18 PM Alberto Ruiz <<a href="mailto:aruiz@redhat.com" target="_blank">aruiz@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 27, 2019 at 12:50 PM Lennart Poettering <<a href="mailto:mzerqung@0pointer.de" target="_blank">mzerqung@0pointer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mi, 25.09.19 16:50, Hans de Goede (<a href="mailto:hdegoede@redhat.com" target="_blank">hdegoede@redhat.com</a>) wrote:<br>
<br>
> Hi all,<br>
><br>
> Currently, at least in Fedora, but I do not believe that this problem is<br>
> unique to Fedora, there are 2 problems with keymap handling in the<br>
> initrd.<br>
<br>
Hmm, why do you need a correct initrd in the early boot? I can see two<br>
reasons:<br>
<br>
1. full disk encryption with the user typing in the password on the<br>
   kbd. But isn't the answer to this to link the root OS to the tpm<br>
   instead, and use user-keyed crypto only for $HOME? The OS itself<br>
   doesn't need to be protected after all, everbody should have the<br>
   same files there anyway, it's $HOME that needs protection.<br></blockquote><div><br></div><div>Some counterarguments here:<br>- The TPM does not protect you from someone stealing your entire laptop and booting from external media,</div></div></div></blockquote><div><br></div><div>It does, because one of the PCRs has the entire boot sequence embedded into it. If you seal the key and then boot something else, the TPM will refuse to unseal the key for you. The same can be applied to hash of the kernel image (and initrds, if someone patched systemd-boot to include them in PCR8), and/or to Secure Boot state as done by Windows.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>- There are plenty of systems out there without a TPM module that Fedora cares about<br></div></div></div></blockquote><div><br></div><div>That's the main problem. Only two of my several still-reasonably-modern x64 machines have TPMs, and one of them is TPM 1.2 which requires the completely unmaintained Trousers stack.</div></div></div></blockquote><div><br></div><div>As a side topic for systemd-homed, I kind of wish Linux had some actual daemon that would take care of TPM stuff, like providing an API to seal keys without requiring the user to care about which PCRs to use and worry about what happens after kernel upgrades, and would work equally with both TPM 2.0 and TPM 1.2. (Kind of like what ChromiumOS.git currently has in its cryptohome bits?)</div><div><br></div><div>I'm not sure if that would be part of systemd(-tpmd), or part of SSSD which has a "secrets" store, or something else.</div><div><br></div><div>I do already have a TPM-locked LUKS root filesystem, and some of the tools involved in setting it up could very well be called "user-hostile". (To be fair they just faithfully replicate the underlying API, but...)</div><div><br></div><div>(As a side topic to the side topic, I've been working on a hack to achieve password-free unlocking like on Windows, but without involving Secure Boot: <a href="https://github.com/grawity/tpm_futurepcr">https://github.com/grawity/tpm_futurepcr</a> -- I'm not sure if it's the brightest idea, but so far it does the job.)</div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>