On Wed, Sep 21, 2022 at 04:15:20PM -0400, Mimi Zohar wrote: > On Tue, 2022-09-20 at 07:36 +0300, Jarkko Sakkinen wrote: > > On Sat, Sep 10, 2022 at 10:40:05PM -0400, Mimi Zohar wrote: > > > On Thu, 2022-09-08 at 08:25 +0300, Jarkko Sakkinen wrote: > > > > On Wed, Sep 07, 2022 at 07:57:27PM -0400, Mimi Zohar wrote: > > > > > On Wed, 2022-09-07 at 13:47 -0700, Evan Green wrote: > > > > > > On Tue, Aug 30, 2022 at 7:48 PM Jarkko Sakkinen <jarkko@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > On Mon, Aug 29, 2022 at 02:51:50PM -0700, Matthew Garrett wrote: > > > > > > > > On Mon, Aug 29, 2022 at 2:45 PM Ken Goldman <kgold@xxxxxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > On 5/4/2022 7:20 PM, Evan Green wrote: > > > > > > > > > > Enabling the kernel to be able to do encryption and integrity checks on > > > > > > > > > > the hibernate image prevents a malicious userspace from escalating to > > > > > > > > > > kernel execution via hibernation resume. [snip] > > > > > > > > > > > > > > > > > > I have a related question. > > > > > > > > > > > > > > > > > > When a TPM powers up from hibernation, PCR 10 is reset. When a > > > > > > > > > hibernate image is restored: > > > > > > > > > > > > > > > > > > 1. Is there a design for how PCR 10 is restored? > > > > > > > > > > > > > > > > I don't see anything that does that at present. > > > > > > > > > > > > > > > > > 2. How are /sys/kernel/security/ima/[pseudofiles] saved and > > > > > > > > > restored? > > > > > > > > > > > > > > > > They're part of the running kernel state, so should re-appear without > > > > > > > > any special casing. However, in the absence of anything repopulating > > > > > > > > PCR 10, they'll no longer match the in-TPM value. > > > > > > > > > > > > > > This feature could still be supported, if IMA is disabled > > > > > > > in the kernel configuration, which I see a non-issue as > > > > > > > long as config flag checks are there. > > > > > > > > > > > > Right, from what I understand about IMA, the TPM's PCR getting out of > > > > > > sync with the in-kernel measurement list across a hibernate (because > > > > > > TPM is reset) or kexec() (because in-memory list gets reset) is > > > > > > already a problem. This series doesn't really address that, in that it > > > > > > doesn't really make that situation better or worse. > > > > > > > > > > For kexec, the PCRs are not reset, so the IMA measurment list needs to > > > > > be carried across kexec and restored. This is now being done on most > > > > > architectures. Afterwards, the IMA measurement list does match the > > > > > PCRs. > > > > > > > > > > Hibernation introduces a different situation, where the the PCRs are > > > > > reset, but the measurement list is restored, resulting in their not > > > > > matching. > > > > > > > > As I said earlier the feature still can be supported if > > > > kernel does not use IMA but obviously needs to be flagged. > > > > > > Jumping to the conclusion that "hibernate" is acceptable for non-IMA > > > enabled kernels misses the security implications of mixing (kexec) non- > > > IMA and IMA enabled kernels. > > > I would prefer some sort of hibernate marker, the equivalent of a > > > "boot_aggregate" record. > > > > Not sure if this matters. If you run a kernel, which is not aware > > of IMA, it's your choice. I don't undestand why here is so important > > to protect user from doing illogical decisions. > > > > If you want non-IMA kernels to support IMA, CONFIG_IMA should not > > probably even exist because you are essentially saying that any > > kernel play well with IMA. > > That will never happen, nor am I suggesting it should. > > Enabling hibernate or IMA shouldn't be an either-or decision, if at all > possible. The main concern is that attestation servers be able to > detect hibernation and possibly the loss of measurement > history. Luckily, although the PCRs are reset, the TPM > pcrUpdateCounter is not. > > I would appreciate including a "hibernate" marker, similar to the > "boot_aggregate". Yeah, I guess that would not do harm. BR, Jarkko
