On Sat, Aug 5, 2017 at 2:50 AM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 4 August 2017 at 22:20, Matthew Garrett <mjg59@xxxxxxxxxx> wrote: >> If a machine is reset while secrets are present in RAM, it may be >> possible for code executed after the reboot to extract those secrets >> from untouched memory. The Trusted Computing Group specified a mechanism >> for requesting that the firmware clear all RAM on reset before booting >> another OS. This is done by setting the MemoryOverwriteRequestControl >> variable at startup. If userspace can ensure that all secrets are >> removed as part of a controlled shutdown, it can reset this variable to >> 0 before triggering a hardware reboot. >> > > Shouldn't it be up to the kernel to decide whether this flag should be > cleared after userspace has indicated to it that it thinks it has > wiped all secrets from memory? The kernel itself may keep secrets as > well, and we may still crash in the time window between userspace > invoking shutdown and the kernel actually calling ResetSystem() in the > firmware. What's the threat model? If there's no way for userland to ask the kernel to drop any secrets it still holds, that seems like a problem in any case. If the concern is that someone may be able to clear the flag and then reboot in order to deliberately attempt to obtain kernel secrets then there's no hugely easy way around this without special casing the variable and preventing userland from being able to modify it. There's a MemoryOverwriteRequestLock spec from Microsoft that provides a mechanism for this (the firmware and the OS configure a shared secret that controls access to MemoryOverwriteRequestControl, so we'd keep that in the kernel and clear it on reboot), but that's not implemented everywhere and we'd still want to base on top of this. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
