[PATCH 00/12] x86/CET: The last 12 patches to enable Intel CET

[Florian Weimer]

On 07/26/2018 01:16 PM, Florian Weimer wrote:
> On 07/21/2018 04:20 PM, H.J. Lu wrote:
>> These are the last 12 patches to enable Intel CET.  Tested by
>>
>> 1. build-many-glibcs.py.
>> 2. With --enable-cet and without --enable-cet for i686, x86-64 and x32
>> on non-CET x86-64 processors.
>> 3. With --enable-cet for x86-64 and x32 on CET SDV using the CET kernel
>> from cet branch at:
>>
>> https://github.com/yyu168/linux_cet/tree/cet
>>
>> When the shadow stack (SHSTK) is enabled, makecontext needs to allocate
>> a new shadow stack to go with the new stack allocated by the caller.
>> setcontext and swapcontext must properly handle the corresponding shadow
>> stack when the stack is switched.  Add more tests for user context
>> functions to provide more coverage for the shadow stack support.
> 
> Building glibc with --enable-cet currently breaks valgrind (even for 
> current CPUs which do not support CET):
> 
>  Â  https://bugzilla.redhat.com/show_bug.cgi?id=1608824
> 
> Mark is working on a valgrind fix.

This has now been fixed (in valgrind-3.13.0-22.fc29.x86_64), but I get 
this instead:

==22== Conditional jump or move depends on uninitialised value(s)
==22==    at 0x10DF43: _dl_process_cet_property_note (dl-prop.h:82)
==22==    by 0x10DF43: _dl_process_pt_note (dl-prop.h:137)
==22==    by 0x10E713: _dl_map_object_from_fd (dl-load.c:1170)
==22==    by 0x11120B: _dl_map_object (dl-load.c:2241)
==22==    by 0x10D92B: dl_main (rtld.c:1050)
==22==    by 0x121A6E: _dl_sysdep_start (dl-sysdep.c:253)
==22==    by 0x10A1D7: _dl_start_final (rtld.c:413)
==22==    by 0x10A1D7: _dl_start (rtld.c:520)
==22==    by 0x109117: ??? (in …/build-x86_64-redhat-linux/elf/ld.so)
==22==    by 0x3: ???
==22==    by 0x1FFF000746: ???
==22==    by 0x1FFF000750: ???
==22==    by 0x1FFF00075F: ???
==22==    by 0x1FFF000770: ???
==22==  Uninitialised value was created by a stack allocation
==22==    at 0x10DE80: _dl_process_pt_note (dl-prop.h:111)

One potential cause could be that note traversal loop is buggy.

GDB says:

(gdb) bt
#0  0x000000000010df43 in _dl_process_cet_property_note 
(align=<optimized out>, size=48, note=0x1ffefff930, l=0x134160)
     at ../sysdeps/x86/dl-prop.h:82
#1  _dl_process_pt_note (l=l@entry=0x134160, ph=ph@entry=0x1fff000018, 
fd=fd@entry=3, fbp=fbp@entry=0x1ffefffe10)
     at ../sysdeps/x86/dl-prop.h:137
#2  0x000000000010e714 in _dl_map_object_from_fd 
(name=name@entry=0x1fff000721 "/usr/bin/true", origname=origname@entry=0x0,
     fd=<optimized out>, fbp=fbp@entry=0x1ffefffe10, realname=<optimized 
out>, loader=loader@entry=0x0, l_type=<optimized out>,
     mode=<optimized out>, stack_endp=<optimized out>, nsid=<optimized 
out>) at dl-load.c:1170
#3  0x000000000011120c in _dl_map_object (loader=loader@entry=0x0, 
name=0x1fff000721 "/usr/bin/true", type=type@entry=0,
     trace_mode=trace_mode@entry=0, mode=mode@entry=536870912, 
nsid=nsid@entry=0) at dl-load.c:2241
#4  0x000000000010d92c in dl_main (phdr=<optimized out>, phnum=10, 
user_entry=0x1fff0003d8, auxv=<optimized out>) at rtld.c:1050
#5  0x0000000000121a6f in _dl_sysdep_start 
(start_argptr=start_argptr@entry=0x1fff0004b0, 
dl_main=dl_main@entry=0x10a610 <dl_main>)
     at ../elf/dl-sysdep.c:253
#6  0x000000000010a1d8 in _dl_start_final (arg=0x1fff0004b0) at rtld.c:413
#7  _dl_start (arg=0x1fff0004b0) at rtld.c:520
#8  0x0000000000109118 in _start ()

The problem seems to be this:

	      unsigned int type = *(unsigned int *) ptr;
	      unsigned int datasz = *(unsigned int *) (ptr + 4);

	      ptr += 8;
	      if ((ptr + datasz) > ptr_end)
		break;

We load datasz and then check for having encountered the last note.  I'm 
checking a fix.

Thanks,
Florian