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.
