Is this intended to protect keys/etc after the attacker has gained the ability to run arbitrary kernel-mode code? If so, that seems optimistic, doesn't it?
Not exactly: there are many types of kernel attack, but mostly the attacker either manages to effect a privilege escalation to root or gets the ability to run a ROP gadget. The object of this code is to be completely secure against root trying to extract the secret (some what similar to the lockdown idea), thus defeating privilege escalation and to provide "sufficient" protection against ROP gadget.
What stops "root" from mapping /dev/mem and reading that memory?
/dev/mem uses the direct map for the copy at least for read/write, so it gets a fault in the same way root trying to use ptrace does. I think we've protected mmap, but Mike would know that better than I.
I'm more concerned about the mmap case -> remap_pfn_range(). Anybody going via the VMA shouldn't see the struct page, at least when vma_normal_page() is properly used; so you cannot detect secretmem memory mapped via /dev/mem reliably. At least that's my theory :)
[...]
Also, there is a way to still read that memory when root by
- Having kdump active (which would often be the case, but maybe not
to dump user pages ) 2. Triggering a kernel crash (easy via proc as root) 3. Waiting for the reboot after kump() created the dump and then reading the content from disk.
Anything that can leave physical memory intact but boot to a kernel where the missing direct map entry is restored could theoretically extract the secret. However, it's not exactly going to be a stealthy extraction ...
Or, as an attacker, load a custom kexec() kernel and read memory from the new environment. Of course, the latter two are advanced mechanisms, but they are possible when root. We might be able to mitigate, for example, by zeroing out secretmem pages before booting into the kexec kernel, if we care :)
I think we could handle it by marking the region, yes, and a zero on shutdown might be useful ... it would prevent all warm reboot type attacks.
Right. But I guess when you're actually root, you can just write a kernel module to extract the information you need (unless we have signed modules, so it could be harder/impossible).