This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V4 [PATCH 04/12] x86/CET: Extend arch_prctl syscall for CET control
- From: Sergey Senozhatsky <sergey dot senozhatsky dot work at gmail dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Sergey Senozhatsky <sergey dot senozhatsky at gmail dot com>
- Date: Mon, 13 Aug 2018 13:51:18 +0900
- Subject: Re: V4 [PATCH 04/12] x86/CET: Extend arch_prctl syscall for CET control
- References: <CAMe9rOqKkgBp7PN9m-L7-r33brXO+Eu_=-7n74B=nS9FEujJhQ@mail.gmail.com>
Hello,
On (07/24/18 09:13), H.J. Lu wrote:
> >>
> >> OK for master?
Did you happen to hear of any regressions related to ARCH_CET prctl?
I just noticed that every app now does -EINVAL ARCH_CET prctl syscalls:
[..]
[ 5.197696] systemctl: Unsupported prctl 3001
[ 5.197702] process: systemctl: Unsupported common prctl 3001
[ 5.207016] checkemail: Unsupported prctl 3001
[ 5.207023] process: checkemail: Unsupported common prctl 3001
[ 5.207245] bash: Unsupported prctl 3001
[ 5.207251] process: bash: Unsupported common prctl 3001
[ 5.209795] fetchmail: Unsupported prctl 3001
[ 5.209801] process: fetchmail: Unsupported common prctl 3001
[ 5.211082] tty: Unsupported prctl 3001
[ 5.211087] process: tty: Unsupported common prctl 3001
[ 5.212223] pidof: Unsupported prctl 3001
[ 5.212228] process: pidof: Unsupported common prctl 3001
[ 5.233192] dircolors: Unsupported prctl 3001
[ 5.233200] process: dircolors: Unsupported common prctl 3001
[ 8.862025] startx: Unsupported prctl 3001
[ 8.862031] process: startx: Unsupported common prctl 3001
[ 8.864556] tty: Unsupported prctl 3001
[ 8.864561] process: tty: Unsupported common prctl 3001
[ 8.865664] expr: Unsupported prctl 3001
[..]
Which is, maybe fine, though I'm not entirely sure since I don't
really see ARCH_CET being supported by any arch (neither in linux-next
nor in Linus' tree), so maybe as of now those syscalls are unneeded.
The part where, I believe, these -EINVAL prctls begin to backfire is
valgrind - I can't run it anymore with glibc 2.28. It gives me the
following error:
:
:valgrind: the 'impossible' happened:
: Unsupported arch_prctl option
:
:host stacktrace:
:==3118== at 0x580441BA: show_sched_status_wrk (m_libcassert.c:355)
:==3118== by 0x580442D4: report_and_quit (m_libcassert.c:426)
:==3118== by 0x58044517: panic (m_libcassert.c:502)
:==3118== by 0x58044517: vgPlain_core_panic_at (m_libcassert.c:507)
:==3118== by 0x5804454A: vgPlain_core_panic (m_libcassert.c:512)
:==3118== by 0x580DAE22: vgSysWrap_amd64_linux_sys_arch_prctl_before (syswrap-amd64-linux.c:286)
:==3118== by 0x580A0C23: vgPlain_client_syscall (syswrap-main.c:1857)
:==3118== by 0x5809D48A: handle_syscall (scheduler.c:1126)
:==3118== by 0x5809EBB6: vgPlain_scheduler (scheduler.c:1443)
:==3118== by 0x580AED50: thread_wrapper (syswrap-linux.c:103)
:==3118== by 0x580AED50: run_a_thread_NORETURN (syswrap-linux.c:156)
:
:sched status:
: running_tid=1
:
:Thread 1: status = VgTs_Runnable (lwpid 3118)
:==3118== at 0x401A035: ??? (in /usr/lib/ld-2.28.so)
:==3118== by 0xBFEBFBFE: ???
:
strace shows 2 prctl calls issued by valgrind, one of them is
-EINVAL ARCH_CET:
arch_prctl(0x3001 /* ARCH_??? */, 0x7ffc4c366a30) = -1 EINVAL (Invalid argument)
arch_prctl(ARCH_SET_FS, 0x7f215f02f500) = 0
So my assumption is that arch_prctl(0x3001) disappoints valgrind to
the point of no return.
Any thoughts? Can ARCH_CET prctls be disabled somehow?
-ss