# Re: \[PATCH v28 09/32\] x86/mm: Introduce \_PAGE\_COW

- From: Yu, Yu-cheng \<hidden\>
- Date: 2021-08-18 16:38:54 
- List: linux-mm
- Page: https://ratatoskr.run/linux-mm/2021/08/1481968
- Thread: https://ratatoskr.run/linux-doc/2021/07/1455208/t.md

```text
On 8/17/2021 2:01 PM, Borislav Petkov wrote:
> On Tue, Aug 17, 2021 at 01:51:52PM -0700, Andy Lutomirski wrote:
>> WRSS can be used from user mode depending on the configuration.
>
> My point being, if you're going to do shadow stack management
> operations, you should check whether the target you're writing to is a
> shadow stack page. Clearly userspace can't do that but userspace will
> get notified of that pretty timely.
>
>> Double-you shmouble-you. You can't write it with MOV, but you can
>> write it from user code and from kernel code. As far as the mm is
>> concerned, I think it should be considered writable.
>
> Because?
>
>> Although... anyone who tries to copy_to_user() it is going to be a bit
>> surprised. Hmm.
>
> Ok, so you see the confusion.
>

copy_to_user() can run into normal read-only areas too.  The caller can handle that just fine.

> In any case, I don't think you can simply look at a shadow stack page as
> simple writable page. There are cases where it is going to be fun.
>
> So why are we even saying that a shadow stack page is writable? Why
> can't we simply say that a shadow stack page is, well, something
> special?
>

We can visualize the type of a mm area by looking at vma->vm_flags, e.g. maybe_mkwrite(), and PTE macros as lower-level operatives.  These two have some relations but not one-to-one.  Note that a PTE in a writable area is not always pte_write().

I have considered and implemented a shadow stack PTE either pte_write() or not.  Making shadow stack as pte_write() results in less arch_* macros and less confusion in copy-on-write code.  That is one more thing to consider.

Thanks,
Yu-cheng

```