On Mon, Mar 6, 2023, at 10:33 AM, Edgecombe, Rick P wrote:

On Mon, 2023-03-06 at 10:15 -0800, Andy Lutomirski wrote:

quoted

On Mon, Mar 6, 2023 at 5:10 AM Borislav Petkov [off-list ref] wrote:

quoted

On Mon, Feb 27, 2023 at 02:29:40PM -0800, Rick Edgecombe wrote:

quoted

The x86 Control-flow Enforcement Technology (CET) feature
includes a new
type of memory called shadow stack. This shadow stack memory has
some
unusual properties, which requires some core mm changes to
function
properly.

Shadow stack memory is writable only in very specific, controlled
ways.
However, since it is writable, the kernel treats it as such. As a
result

                                                                   
        ^
                                                                   
        ,

quoted

there remain many ways for userspace to trigger the kernel to
write to
shadow stack's via get_user_pages(, FOLL_WRITE) operations. To
make this a

Is there an alternate mechanism, or do we still want to allow
FOLL_FORCE so that debuggers can write it?

Yes, GDB shadow stack support uses it via both ptrace poke and
/proc/pid/mem apparently. So some ability to write through is needed
for debuggers. But not CRIU actually. It uses WRSS.

There was also some discussion[0] previously about how apps might
prefer to block /proc/self/mem for general security reasons. Blocking
shadow stack writes while you allow text writes is probably not that
impactful security-wise. So I thought it would be better to leave the
logic simpler. Then when /proc/self/mem could be locked down per the
discussion, shadow stack can be locked down the same way.

Ah, I am guilty of reading your changelog but not the code.

You said:

Shadow stack memory is writable only in very specific, controlled ways.
However, since it is writable, the kernel treats it as such. As a result
there remain many ways for userspace to trigger the kernel to write to
shadow stack's via get_user_pages(, FOLL_WRITE) operations. To make this a
little less exposed, block writable GUPs for shadow stack VMAs.

I read that as *denying* FOLL_FORCE.  Maybe clarify the changelog?

[0] 
https://lore.kernel.org/lkml/E857CF98-EEB2-4F83-8305-0A52B463A661@kernel.org/ (local)