Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas

[David Hildenbrand]

> > > > 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