1. 6
  1.  

  2. 1

    Hibernation is bad for secrets? Ha. FreeBSD never supported hibernation in the first place :D so it would be even easier for us to adopt this API.

    1. 1

      I’m struggling a bit to understand the threat model here. Presumably the hibernation file, like swap, is encrypted and so it’s defending against someone able to run code that leaks the secret via side channels while it’s in the kernel’s direct map and not encrypted. This feels like it should be easy to avoid: during hibernation, you stop all userspace processes running and so if you don’t expose, encrypt, and store the secret pages until after you’ve stopped userspace then the only things that can leak the secrets are other kernel threads. If an attacker can run code in the kernel, they can update page tables and add the page of secrets into the direct map (or anywhere else).

      It sounds as if this API is of pretty limited use in general because if it’s allocating pages that can’t be paged out (swapping is harder than hibernating because you don’t want to pause all userspace threads while you encrypt / decrypt a page of secrets) then it needs to be subject to the same resource controls as wired pages (i.e. root only, small number in total only). Most of the things where root has secrets that need protecting are better handled by a TPM or the platform’s equivalent and then they’re protected from the kernel as well.

      1. 2

        You’re not the only one. There are multiple separate flame wars in the LWN comments over there which appear to be caused or exacerbated by a total lack of explanation of the threat model.

        1. 1

          If you encrypt the hibernation file, where does the key go?

          same resource controls as wired pages (i.e. root only, small number in total only)

          But why root only? Why can’t each user have some wired pages too? Actually isn’t there a per-user mlock limit already?

          1. 1

            If you encrypt the hibernation file, where does the key go?

            In the TPM? Again, it depends a bit on your threat model. The attack on the hibernation file is that you hibernate and then you have the data sitting on disk so the attacker can boot another OS and read it. They can’t boot the current OS and read it because the current kernel is in the TCB and is guaranteed to enforce a policy that prevents access. If you’re not doing secure boot, then it would be trivial for an attacker who has access to the disk to just tamper with your kernel, so the key storage location doesn’t matter. If you are doing secure boot, then protecting the key in the TPM means that the hibernation file is accessible only to the kernel (or bootloader) with the same code and initial state as the the one that generated it.

            I’m still trying to understand what the threat model is. I guess it almost makes sense if it’s about systems without secure boot and an attacker who can access the disk image during hibernation but can’t return the computer with a modified kernel and make you reenter any credentials, but if the attacker has physical access and you are in a non-hibernate sleep state (and you’re not doing full memory encryption) then they can also trivially do a cold-boot attack and just read the data out of memory. So I’m still struggling to understand what the threat model actually is.

            But why root only? Why can’t each user have some wired pages too? Actually isn’t there a per-user mlock limit already?

            I actually don’t know what the current policy is on modern *NIX systems. Historically, the ability to wire pages was limited to root because it’s very easy to consume enough that the system crashes and on a system with a lot of users then even a small per-user limit can exhaust memory if everyone uses it at once. On a mostly single-user system, that’s probably less of an issue.