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
1. 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).
--
Thanks,
David / dhildenb
