On Mon, 2023-03-06 at 10:57 -0800, Andy Lutomirski wrote: > 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: > > > On Mon, Mar 6, 2023 at 5:10 AM Borislav Petkov <bp@xxxxxxxxx> > > > wrote: > > > > > > > > On Mon, Feb 27, 2023 at 02:29:40PM -0800, Rick Edgecombe wrote: > > > > > 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 > > > > > > > > > > > > > > > > ^ > > > > > > > > > > > > , > > > > > > > > > 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? I think maybe some helpful text missed the quote in Boris comment about other issues: "Still allow FOLL_FORCE to write through shadow stack protections, as it does for read-only protections." But, yea, the tenses are hard to parse. Maybe something like this: 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. In userspace, shadow stack memory is writable only in very specific, controlled ways. However, since userspace can, even in the limited ways, modify shadow stack contents, the kernel treats it as writable memory. As a result, without additional work there would remain many ways for userspace to trigger the kernel to write arbitrary data to shadow stacks via get_user_pages(, FOLL_WRITE) based operations. To help userspace protect their shadow stacks, make this a little less exposed by blocking writable get_user_pages() operations for shadow stack VMAs. Still allow FOLL_FORCE to write through shadow stack protections, as it does for read-only protections. This is required for debugging use cases.
