Thread (10 messages) 10 messages, 5 authors, 2023-01-25

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

From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Date: 2023-01-24 18:43:12
Also in: linux-arch, linux-doc, linux-mm, lkml

Possibly related (same subject, not in this thread)

Ping Cristina regarding GDB.

Ping Kees regarding /proc/self/mem.

On Tue, 2023-01-24 at 17:26 +0100, David Hildenbrand wrote:
quoted
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help