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]

 



> > 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.
> 
> Our patches for GDB use /proc/PID/mem to read/write shadow stack
> memory.
> However, I think it should be possible to change this to ptrace but GDB
> normally uses /proc/PID/mem to read/write target memory.
> 
> Regards,
> Christina

I just noticed that GDBSERVER actually uses ptrace, so our patches currently use
both: ptrace and proc/PID/mem to read/write shadow stack memory.

Regards,
Christina
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux