This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/12] x86/CET: The last 12 patches to enable Intel CET
On Fri, Jul 27, 2018 at 7:53 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 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.
How can I reproduce it?
[hjl@gnu-cfl-1 build-x86_64-linux]$ strace ./misc/tst-mntent --direct
execve("./misc/tst-mntent", ["./misc/tst-mntent", "--direct"],
0x7ffca647e038 /* 70 vars */) = 0
brk(NULL) = 0x205c000
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd122d56f0) = -1 EINVAL (Invalid argument)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fce93e8a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
...
[hjl@gnu-cfl-1 build-x86_64-linux]$ valgrind ./misc/tst-mntent --direct
==21245== Memcheck, a memory error detector
==21245== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==21245== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==21245== Command: ./misc/tst-mntent --direct
==21245==
Found!
==21245==
==21245== HEAP SUMMARY:
==21245== in use at exit: 552 bytes in 1 blocks
==21245== total heap usage: 3 allocs, 2 frees, 8,744 bytes allocated
==21245==
==21245== LEAK SUMMARY:
==21245== definitely lost: 0 bytes in 0 blocks
==21245== indirectly lost: 0 bytes in 0 blocks
==21245== possibly lost: 0 bytes in 0 blocks
==21245== still reachable: 552 bytes in 1 blocks
==21245== suppressed: 0 bytes in 0 blocks
==21245== Rerun with --leak-check=full to see details of leaked memory
==21245==
==21245== For counts of detected and suppressed errors, rerun with: -v
==21245== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
[hjl@gnu-cfl-1 build-x86_64-linux]$
--
H.J.