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

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

quoted

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.

Ok, separate them.

quoted

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.

So we will always reserve a big space for all CET tasks?

Currently if an application does dlopen() a legacy lib, it will have only
partial IBT protection and no SHSTK.  Do we want to consider simply turning
off IBT in that case?

Yu-cheng