On January 24, 2023 10:42:28 AM PST, "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx> wrote: >Ping Cristina regarding GDB. > >Ping Kees regarding /proc/self/mem. > >On Tue, 2023-01-24 at 17:26 +0100, David Hildenbrand wrote: >> > > 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 question is, if there is reasonable debugging reason to keep it. >> I >> assume if a debugger would adjust the ordinary stack, it would have >> to >> adjust the shadow stack as well (oh my ...). So it sounds reasonable >> to >> have it in theory at least ... not sure when debugger would support >> that, but maybe they already do. > >GDB support for shadow stack is queued up for whenever the kernel >interface settles. I believe it just uses ptrace, and not this proc. >But yea ptrace poke will still need to use FOLL_FORCE and be able to >write through shadow stacks. I'd prefer to avoid adding more FOLL_FORCE if we can. If gdb can do stack manipulations through a ptrace interface then let's leave off FOLL_FORCE. -Kees > >> >> > 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. >> >> I agree with that. It's a debugging mechanism that a process can >> abuse >> to do nasty stuff to its memory that it maybe shouldn't be able to do >> ... > >Ok. -- Kees Cook
