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

[Kees Cook]

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