Re: RFC: Update x86 psABI to support shadow stac

Re: RFC: Update x86 psABI to support shadow stac

[H.J. Lu]

On Thu, Jun 22, 2017 at 6:10 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/22/2017 03:01 PM, H.J. Lu wrote:
>> On Thu, Jun 22, 2017 at 5:51 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/21/2017 05:25 PM, H.J. Lu wrote:
>>>> GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
>>>> all relocatable inputs, which means that the C library must be compiled
>>>> with SHSTK-enabled compiler.
>>>
>>> I don't think this is sufficiently detailed for an ABI specification.
>>> It needs to say what an SHSTK-enabled compiler does.
>>
>> Compilers just need to make return address popped from shadow
>> stack match return address popped from normal stack.
>
> Nothing else?  Would a writable GOT still be fine?

Writable GOT is OK.

> The responsibilities for compliance are split between caller and callee,
> which can live in different shared objects.  I think it would be prudent
> to formulate the requirement in such a way that compliance can be
> checked by looking at one DSO in isolation.

What do you mean by it?

> Is there a requirement that the return address is popped from the same
> stack location where it was pushed by the call instruction?  Or could
> you return with an elevated stack pointer if you copied the address first?

Stack location isn't checked.  Only the popped return address is checked.
Vedvyas can confirm it.


-- 
H.J.

Re: RFC: Update x86 psABI to support shadow stac

[H.J. Lu]

On Wed, Jun 28, 2017 at 2:58 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/22/2017 08:44 PM, H.J. Lu wrote:
>>> The responsibilities for compliance are split between caller and callee,
>>> which can live in different shared objects.  I think it would be prudent
>>> to formulate the requirement in such a way that compliance can be
>>> checked by looking at one DSO in isolation.
>
>> What do you mean by it?
>
> I suggest to word the ABI requirement in such a way that it is possible
> to verify if a shared object complies with it isolation, independent of
> how its functions are called.
>

99% of existing binaries are compatible with shadow stack.  It is hard
to tell just by looking at assembly instructions.  If shadow stack is enabled,
compiler should turn on the SHSTK bit in output:

[hjl@gnu-tools-1 32]$ readelf -n crtprec32.o

Displaying notes found in: .note.gnu.property
  Owner                 Data size Description
  GNU                  0x0000000c NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT
  GNU                  0x0000000c NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: SHSTK
[hjl@gnu-tools-1 32]$

I don't know if it is sufficient for verification.


-- 
H.J.

RFC: Update x86 psABI to support shadow stac

[H.J. Lu]

Any comments?

-- 
H.J.
---
To support shadow stack (SHSTK) in Intel Control-flow Enforcement
Technology (CET) instructions:

https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforc
ement-technology-preview.pdf

following changes to x86 psABI are required.

To program properties, add

#define GNU_PROPERTY_X86_FEATURE_1_SHSTK (1U << 1)

to the GNU_PROPERTY_X86_FEATURE_1_AND property to indicate that all
executable sections are compatible with SHSTK where return address
popped from shadow stack always matches return address popped from
normal stack.

GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
all relocatable inputs, which means that the C library must be compiled
with SHSTK-enabled compiler.

Load-time processing

On a SHSTK capable processor, the following steps should be taken:

1. When loading an executable, if GNU_PROPERTY_X86_FEATURE_1_SHSTK is
set on the executable as well as all shared objects loaded via the
DT_NEEDED tag, enable SHSTK.
2. After SHSTK is enabled, it is an error to load a shared object
without GNU_PROPERTY_X86_FEATURE_1_SHSTK.
gnu-6:pts/8[8]> cat  shstk.txt                /export/gnu/import/git/properties
Update x86 psABI to support shadow stack

To support shadow stack (SHSTK) in Intel Control-flow Enforcement
Technology (CET) instructions:

https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf

following changes to x86 psABI are required.

To program properties, add

#define GNU_PROPERTY_X86_FEATURE_1_SHSTK (1U << 1)

to the GNU_PROPERTY_X86_FEATURE_1_AND property to indicate that all
executable sections are compatible with SHSTK where return address
popped from shadow stack always matches return address popped from
normal stack.

GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
all relocatable inputs, which means that the C library must be compiled
with SHSTK-enabled compiler.

Load-time processing

On a SHSTK capable processor, the following steps should be taken:

1. When loading an executable, if GNU_PROPERTY_X86_FEATURE_1_SHSTK is
set on the executable as well as all shared objects loaded via the
DT_NEEDED tag, enable SHSTK.
2. After SHSTK is enabled, it is an error to load a shared object
without GNU_PROPERTY_X86_FEATURE_1_SHSTK.

RE: RFC: Update x86 psABI to support shadow stac

[Shanbhogue, Vedvyas]

>> Is there a requirement that the return address is popped from the same 
>> stack location where it was pushed by the call instruction?  Or could 
>> you return with an elevated stack pointer if you copied the address first?

> Stack location isn't checked.  Only the popped return address is checked.
> Vedvyas can confirm it.

Yes. That’s correct. 

Re: RFC: Update x86 psABI to support shadow stac

[Florian Weimer]

On 06/22/2017 03:01 PM, H.J. Lu wrote:
> On Thu, Jun 22, 2017 at 5:51 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 06/21/2017 05:25 PM, H.J. Lu wrote:
>>> GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
>>> all relocatable inputs, which means that the C library must be compiled
>>> with SHSTK-enabled compiler.
>>
>> I don't think this is sufficiently detailed for an ABI specification.
>> It needs to say what an SHSTK-enabled compiler does.
> 
> Compilers just need to make return address popped from shadow
> stack match return address popped from normal stack.

Nothing else?  Would a writable GOT still be fine?

The responsibilities for compliance are split between caller and callee,
which can live in different shared objects.  I think it would be prudent
to formulate the requirement in such a way that compliance can be
checked by looking at one DSO in isolation.

Is there a requirement that the return address is popped from the same
stack location where it was pushed by the call instruction?  Or could
you return with an elevated stack pointer if you copied the address first?

Thanks,
Florian

Re: RFC: Update x86 psABI to support shadow stac

[H.J. Lu]

On Thu, Jun 22, 2017 at 5:51 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/21/2017 05:25 PM, H.J. Lu wrote:
>> GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
>> all relocatable inputs, which means that the C library must be compiled
>> with SHSTK-enabled compiler.
>
> I don't think this is sufficiently detailed for an ABI specification.
> It needs to say what an SHSTK-enabled compiler does.

Compilers just need to make return address popped from shadow
stack match return address popped from normal stack.

-- 
H.J.

Re: RFC: Update x86 psABI to support shadow stac

[Florian Weimer]

On 06/22/2017 08:44 PM, H.J. Lu wrote:
>> The responsibilities for compliance are split between caller and callee,
>> which can live in different shared objects.  I think it would be prudent
>> to formulate the requirement in such a way that compliance can be
>> checked by looking at one DSO in isolation.

> What do you mean by it?

I suggest to word the ABI requirement in such a way that it is possible
to verify if a shared object complies with it isolation, independent of
how its functions are called.

Thanks,
Florian

Re: RFC: Update x86 psABI to support shadow stac

[Florian Weimer]

On 06/21/2017 05:25 PM, H.J. Lu wrote:
> GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on
> all relocatable inputs, which means that the C library must be compiled
> with SHSTK-enabled compiler.

I don't think this is sufficiently detailed for an ABI specification.
It needs to say what an SHSTK-enabled compiler does.

Thanks,
Florian

Re: RFC: Update x86 psABI to support shadow stac

[Florian Weimer]

On 07/27/2017 06:21 PM, H.J. Lu wrote:
> On Thu, Jul 27, 2017 at 8:44 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 06/28/2017 01:21 PM, H.J. Lu wrote:
>>> On Wed, Jun 28, 2017 at 2:58 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>> On 06/22/2017 08:44 PM, H.J. Lu wrote:
>>>>>> The responsibilities for compliance are split between caller and callee,
>>>>>> which can live in different shared objects.  I think it would be prudent
>>>>>> to formulate the requirement in such a way that compliance can be
>>>>>> checked by looking at one DSO in isolation.
>>>>
>>>>> What do you mean by it?
>>>>
>>>> I suggest to word the ABI requirement in such a way that it is possible
>>>> to verify if a shared object complies with it isolation, independent of
>>>> how its functions are called.
>>>>
>>>
>>> 99% of existing binaries are compatible with shadow stack.
>>
>> I find that surprising, or does this number to refer to x86-64 binaries
>> only?
> 
> CET is x86 specific.  You can take a look at the current CET changes for
> GCC at
> 
> https://github.com/hjl-tools/gcc/tree/hjl/cet/reorg16

So i386 is supported?  Then I find your claim about 99% compatibility
surprising because LLVM uses this instruction sequence

	calll	.L0$pb
.L0$pb:
	popl	%ebx
.Ltmp0:
	addl	$_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %ebx

to set %ebx to the GOT pointer.

Older GCC did as well for some CPU tunings, until:

  https://gcc.gnu.org/ml/gcc-patches/2011-06/msg02295.html

Thanks,
Florian

Re: RFC: Update x86 psABI to support shadow stac

[Florian Weimer]

On 06/28/2017 01:21 PM, H.J. Lu wrote:
> On Wed, Jun 28, 2017 at 2:58 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 06/22/2017 08:44 PM, H.J. Lu wrote:
>>>> The responsibilities for compliance are split between caller and callee,
>>>> which can live in different shared objects.  I think it would be prudent
>>>> to formulate the requirement in such a way that compliance can be
>>>> checked by looking at one DSO in isolation.
>>
>>> What do you mean by it?
>>
>> I suggest to word the ABI requirement in such a way that it is possible
>> to verify if a shared object complies with it isolation, independent of
>> how its functions are called.
>>
> 
> 99% of existing binaries are compatible with shadow stack.

I find that surprising, or does this number to refer to x86-64 binaries
only?

> It is hard
> to tell just by looking at assembly instructions.  If shadow stack is enabled,
> compiler should turn on the SHSTK bit in output:
> 
> [hjl@gnu-tools-1 32]$ readelf -n crtprec32.o
> 
> Displaying notes found in: .note.gnu.property
>   Owner                 Data size Description
>   GNU                  0x0000000c NT_GNU_PROPERTY_TYPE_0
>       Properties: x86 feature: IBT
>   GNU                  0x0000000c NT_GNU_PROPERTY_TYPE_0
>       Properties: x86 feature: SHSTK
> [hjl@gnu-tools-1 32]$
> 
> I don't know if it is sufficient for verification.

The ABI document needs to specify what the flag means.  I don't think
it's sufficient to essentially say, “the toolchain did or did not do
some unspecified stuff and we believe the binary is now compatible with
the shadow stack feature”.

Florian

Re: RFC: Update x86 psABI to support shadow stac

[H.J. Lu]

On Thu, Jul 27, 2017 at 8:44 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 06/28/2017 01:21 PM, H.J. Lu wrote:
>> On Wed, Jun 28, 2017 at 2:58 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/22/2017 08:44 PM, H.J. Lu wrote:
>>>>> The responsibilities for compliance are split between caller and callee,
>>>>> which can live in different shared objects.  I think it would be prudent
>>>>> to formulate the requirement in such a way that compliance can be
>>>>> checked by looking at one DSO in isolation.
>>>
>>>> What do you mean by it?
>>>
>>> I suggest to word the ABI requirement in such a way that it is possible
>>> to verify if a shared object complies with it isolation, independent of
>>> how its functions are called.
>>>
>>
>> 99% of existing binaries are compatible with shadow stack.
>
> I find that surprising, or does this number to refer to x86-64 binaries
> only?

CET is x86 specific.  You can take a look at the current CET changes for
GCC at

https://github.com/hjl-tools/gcc/tree/hjl/cet/reorg16

>> It is hard
>> to tell just by looking at assembly instructions.  If shadow stack is enabled,
>> compiler should turn on the SHSTK bit in output:
>>
>> [hjl@gnu-tools-1 32]$ readelf -n crtprec32.o
>>
>> Displaying notes found in: .note.gnu.property
>>   Owner                 Data size Description
>>   GNU                  0x0000000c NT_GNU_PROPERTY_TYPE_0
>>       Properties: x86 feature: IBT
>>   GNU                  0x0000000c NT_GNU_PROPERTY_TYPE_0
>>       Properties: x86 feature: SHSTK
>> [hjl@gnu-tools-1 32]$
>>
>> I don't know if it is sufficient for verification.
>
> The ABI document needs to specify what the flag means.  I don't think
> it's sufficient to essentially say, “the toolchain did or did not do
> some unspecified stuff and we believe the binary is now compatible with
> the shadow stack feature”.
>

Please see CET x86-64 psABI:

https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI

and let me know if they are sufficient.

Thanks.

-- 
H.J.

Re: RFC: Update x86 psABI to support shadow stac

[H.J. Lu]

On Fri, Jul 28, 2017 at 7:59 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 07/27/2017 06:21 PM, H.J. Lu wrote:
>> On Thu, Jul 27, 2017 at 8:44 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/28/2017 01:21 PM, H.J. Lu wrote:
>>>> On Wed, Jun 28, 2017 at 2:58 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>>> On 06/22/2017 08:44 PM, H.J. Lu wrote:
>>>>>>> The responsibilities for compliance are split between caller and callee,
>>>>>>> which can live in different shared objects.  I think it would be prudent
>>>>>>> to formulate the requirement in such a way that compliance can be
>>>>>>> checked by looking at one DSO in isolation.
>>>>>
>>>>>> What do you mean by it?
>>>>>
>>>>> I suggest to word the ABI requirement in such a way that it is possible
>>>>> to verify if a shared object complies with it isolation, independent of
>>>>> how its functions are called.
>>>>>
>>>>
>>>> 99% of existing binaries are compatible with shadow stack.
>>>
>>> I find that surprising, or does this number to refer to x86-64 binaries
>>> only?
>>
>> CET is x86 specific.  You can take a look at the current CET changes for
>> GCC at
>>
>> https://github.com/hjl-tools/gcc/tree/hjl/cet/reorg16
>
> So i386 is supported?  Then I find your claim about 99% compatibility

Yes, i386 is supported.

> surprising because LLVM uses this instruction sequence
>
>         calll   .L0$pb
> .L0$pb:
>         popl    %ebx
> .Ltmp0:
>         addl    $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %ebx
>
> to set %ebx to the GOT pointer.
>

This is called "call 0" and it won't push on shadow stack.  CET
document will be updated to reflect it.


-- 
H.J.