On Mon, 2022-02-07 at 16:13 -0800, Dave Hansen wrote:

On 1/30/22 13:18, Rick Edgecombe wrote:

quoted

The x86 family of processors do not directly create read-only and
Dirty
PTEs.  These PTEs are created by software.

That's not strictly correct.

There's nothing in the architecture today to prevent the CPU from
creating Write=0,Dirty=1 PTEs.  In fact, some CPUs do this in weird
situations.  It wouldn't be wrong to say:

	Processors sometimes directly create read-only and Dirty PTEs.

which is the opposite of what is written above.  This is why the CET
spec has the blurb about shadow-stack-supporting CPUs promise not to
do
this any more.

Yea, it's wrong. The whole point of the new assurance is that it could
before as you say.

quoted

One such case is that kernel
read-only pages are historically setup as Dirty.

				   ^ set up

quoted

New processors that support Shadow Stack regard read-only and Dirty
PTEs as
shadow stack pages.

This also isn't *quite* correct.  It's not just having a new
processor,
it includes enabling shadow stacks.

Right.

quoted

This results in ambiguity between shadow stack and kernel read-only
pages.  To resolve this, removed Dirty from kernel read- only
pages.

One thing that's not clear from the spec: does this cause an *actual*
problem?  For instance, does setting:

	IA32_U_CET.SH_STK_EN=1
but
	IA32_S_CET.SH_STK_EN=0

means that shadow stacks are enforced in user *MODE* or on
user-paging-permission (U=0) PTEs?

I think it's modes, but it would be nice to be clear.  *BUT*, if this
is
accurate, doesn't it also mean that this patch is not strictly
necessary?

Don't get me wrong, the patch is probably still a good idea, but
let's
make sure we get the exact reasoning clear.

Yea, I think this is just a tying up loose ends thing. It is not
functionally needed until there would be shadow stack mode for kernel.
I'll update the patch to make this clear.