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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux