On Tue, Dec 19, 2017 at 2:25 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Tue, Dec 19, 2017 at 09:42:11AM +0000, Tsimbalist, Igor V wrote:
>> > I don't see any discussion in the bugzilla issue to explain this.
>>
>> This option is needed to support two cases:
>>
>> 1. Compilation of ucontext functions inside glibc. To have glibc itself be
>> CET
>> compatible all files comprises the library has to be CET compatible. That
>> means
>> the module with ucontext functions from glibc has to be forced to be CET
>> compatible.
>>
>> 2. Compilation of a user application with ucontext functions. In this case
>> the
>> error has to be issued, so no usage of a ucontext functions.
>>
>> Having just __SHSTK__ macro it's impossible to handle both cases. The case
>> #1 will report an error during glibc compilation. A new macro is introduced
>> to
>> use in the source to handle these cases. To control the value of the new
>> macro
>> a new option is introduced.
>
> That doesn't make sense. Just add
>
> #if defined(__SHSTK__) && !defined(_LIBC)
> #define __UCONTEXT_UNSUPPORTED \
> __attribute__((__error__ ("-mshstk incompatible with ucontext.h APIs")))
> #else
> #define __UCONTEXT_UNSUPPORTED
> #endif
>
> and use __UCONTEXT_UNSUPPORTED on the 4 function declarations, you'll be
> able to compile glibc itself, but not something against it.
This isn't sufficient. I did get
../sysdeps/unix/sysv/linux/x86/tst-ucontext-1a.c:25:10: error: call to
\u2018getcontext\u2019 declared with attribute error: -mshstk
incompatible with ucontext.h APIs
return getcontext (ucp);
But there is no error for
void *p = getcontext;
I am using
#if defined(__SHSTK__) && !defined(_LIBC)
# error -mshstk incompatible with ucontext.h APIs
#endif
> Have you considered implementing these 4 functions or some helper they could
> use in the kernel if CET is enabled and doing there with the shadow stack
> whatever is needed?
>
The main issue is how to allocate and destroy shadow stack within these
functions. We will revisit it after the rest of glibc is CET enabled.
--
H.J.
