Support for Intel's LASS

Posted Jan 13, 2023 18:03 UTC (Fri) by hansendc (subscriber, #7363)
In reply to: Support for Intel's LASS by mb
Parent article: Support for Intel's LASS

Even without rebooting, you can also see if vsyscall emulation is being used:

echo 1 > /sys/kernel/debug/tracing/events/vsyscall/emulate_vsyscall/enable
cat /sys/kernel/debug/tracing/trace_pipe

Running tools/testing/selftests/x86/test_vsyscall_64 will let you know whether the tracing is working or not.

BTW, if you run across a real program that cares, please do let us know.

Support for Intel's LASS

Posted Jan 13, 2023 18:42 UTC (Fri) by adobriyan (subscriber, #30858) [Link] (6 responses)

> BTW, if you run across a real program that cares, please do let us know.

Building RHEL6 kernel in a container requires vsyscall=emulate.

Support for Intel's LASS

Posted Jan 13, 2023 20:07 UTC (Fri) by geofft (subscriber, #59789) [Link] (3 responses)

The manylinux project (widely-compatible base ABI for Python builds) ran into this with CentOS 6, too.

The solution we ended up going with was patching glibc to remove vsyscall support. The build scripts for that appear to be here: https://github.com/pypa/manylinux/tree/v2022.07.10-manyli...

You can probably use the pre-built quay.io/pypa/manylinux2010_x86_64_centos6_no_vsyscall:2020-12-19-cd3e980 container, which contains the result of that build. For your use case of compiling RHEL 6 kernels, that should work.

I also wrote a userspace vsyscall emulator using ptrace as an alternative: https://github.com/pypa/manylinux/pull/158/files It definitely will cause a performance hit because every syscall will trap into the ptracer, but for the commenter above who has a proprietary program, this might be what you need. (Though, really, this should only be a problem for proprietary programs that make syscalls directly, e.g. by being static binaries; if they call into the system libc to make syscalls, then using a newer libc should be enough.)

Support for Intel's LASS

Posted Jan 17, 2023 17:50 UTC (Tue) by luto (guest, #39314) [Link] (2 responses)

That hack seems unlikely to work with if LASS is enabled.

Support for Intel's LASS

Posted Jan 17, 2023 18:54 UTC (Tue) by geofft (subscriber, #59789) [Link] (1 responses)

LASS generates a GPF if you access something with the high bit set, right? Wouldn't that show up to userspace as a SIGBUS or something? You'd probably have to change the == SIGSEGV check in the code, but as long as it sends a catchable signal, there should be a way to make it work.

(Of course if you can use a non-vsyscall libc, that would be better....)

Support for Intel's LASS

Posted Jan 17, 2023 21:40 UTC (Tue) by luto (guest, #39314) [Link]

I’m still hoping for clarification, but I’m suspicious that RIP will point to the CALL into the vsyscall page, not into the vsyscall page.

Support for Intel's LASS

Posted Jan 14, 2023 9:07 UTC (Sat) by dottedmag (subscriber, #18590) [Link]

Isn't RHEL6 ELS ended on Nov 30, 2022?

Support for Intel's LASS

Posted Jan 18, 2023 0:25 UTC (Wed) by judas_iscariote (guest, #47386) [Link]

correct it is an annoying bug on a distribution that is out of support. burn it with fire!