On 07/11/2018 04:00 PM, Yu-cheng Yu wrote:

On Wed, 2018-07-11 at 15:40 -0700, Dave Hansen wrote:

quoted

On 07/11/2018 03:10 PM, Yu-cheng Yu wrote:

quoted

On Tue, 2018-07-10 at 17:11 -0700, Dave Hansen wrote:

quoted

Is this feature *integral* to shadow stacks?  Or, should it just
be
in a
different series?

The whole CET series is mostly about SHSTK and only a minority for
IBT.
IBT changes cannot be applied by itself without first applying
SHSTK
changes.  Would the titles help, e.g. x86/cet/ibt, x86/cet/shstk,
etc.?

That doesn't really answer what I asked, though.

Do shadow stacks *require* IBT?  Or, should we concentrate on merging
shadow stacks themselves first and then do IBT at a later time, in a
different patch series?

But, yes, better patch titles would help, although I'm not sure
that's
quite the format that Ingo and Thomas prefer.

Shadow stack does not require IBT, but they complement each other.  If
we can resolve the legacy bitmap, both features can be merged at the
same time.

As large as this patch set is, I'd really prefer to see you get shadow
stacks merged and then move on to IBT.  I say separate them.

GLIBC does the bitmap setup.  It sets bits in there.
I thought you wanted a smaller bitmap?  One way is forcing legacy libs
to low address, or not having the bitmap at all, i.e. turn IBT off.

I'm concerned with two things:
1. the virtual address space consumption, especially the *default* case
   which will be apps using 4-level address space amounts, but having
   5-level-sized tables.
2. the driving a truck-sized hole in the address space limits

You can force legacy libs to low addresses, but you can't stop anyone
from putting code into a high address *later*, at least with the code we
have today.

quoted

quoted

quoted

quoted

+	rdmsrl(MSR_IA32_U_CET, r);
+	r &= ~(MSR_IA32_CET_ENDBR_EN | MSR_IA32_CET_LEG_IW_EN
|
+	       MSR_IA32_CET_NO_TRACK_EN);
+	wrmsrl(MSR_IA32_U_CET, r);
+	current->thread.cet.ibt_enabled = 0;
+}

What's the locking for current->thread.cet?

Now CET is not locked until the application calls ARCH_CET_LOCK.

No, I mean what is the in-kernel locking for the current->thread.cet
data structure?  Is there none because it's only every modified via
current->thread and it's entirely thread-local?

Yes, that is the case.