Re: [PATCH v5 23/39] mm: Don't allow write GUPs to shadow stack memory

[Edgecombe, Rick P]

On Mon, 2023-01-23 at 11:45 +0100, Florian Weimer wrote:
> * David Hildenbrand:
> 
> > On 19.01.23 22:23, Rick Edgecombe wrote:
> > > The x86 Control-flow Enforcement Technology (CET) feature
> > > includes a new
> > > type of memory called shadow stack. This shadow stack memory has
> > > some
> > > unusual properties, which requires some core mm changes to
> > > function
> > > properly.
> > > Shadow stack memory is writable only in very specific, controlled
> > > ways.
> > > However, since it is writable, the kernel treats it as such. As a
> > > result
> > > there remain many ways for userspace to trigger the kernel to
> > > write to
> > > shadow stack's via get_user_pages(, FOLL_WRITE) operations. To
> > > make this a
> > > little less exposed, block writable GUPs for shadow stack VMAs.
> > > Still allow FOLL_FORCE to write through shadow stack protections,
> > > as
> > > it
> > > does for read-only protections.
> > 
> > So an app can simply modify the shadow stack itself by writing to
> > /proc/self/mem ?
> > 
> > Is that really intended? Looks like security hole to me at first
> > sight, but maybe I am missing something important.
> 
> Isn't it possible to overwrite GOT pointers using the same vector?
> So I think it's merely reflecting the status quo.

There was some debate on this. /proc/self/mem can currently write
through read-only memory which protects executable code. So should
shadow stack get separate rules? Is ROP a worry when you can overwrite
executable code?

The consensus seemed to lean towards not making special rules for this
case, and there was some discussion that /proc/self/mem should maybe be
hardened generally.