Bug 1876977 - Please change the vsyscall config to CONFIG_LEGACY_VSYSCALL_XONLY
Summary: Please change the vsyscall config to CONFIG_LEGACY_VSYSCALL_XONLY
Keywords:
Status: POST
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Herton R. Krzesinski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-09-08 15:50 UTC by Andy Lutomirski
Modified: 2021-12-24 17:38 UTC (History)
21 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab cki-project kernel-ark merge_requests 1531 0 None None None 2021-12-21 14:51:11 UTC

Description Andy Lutomirski 2020-09-08 15:50:17 UTC
The Fedora kernel configs have CONFIG_LEGACY_VSYSCALL_EMULATE=y, which enables vsyscall emulation.  This is superseded by CONFIG_LEGACY_VSYSCALL_XONLY, which should work just as well.  XONLY mode prevents the use of the vsyscall page as an ASLR-bypassing readable page with known contents (yes, an attack like this has actually been demonstrated).  It also blocks access to the nasty kernel mechanism that allows ptrace() to read the vsyscall page, which means it would prevent exploitation of the recent, no-CVE-yet page refcount underflow in that code path.

The only down side I'm aware of is that using outdated versions of Pin (an open-source Intel tool) in conjunction with outdated glibc versions will not work in XONLY mode.  New versions of Pin will work even with old binaries in XONLY mode, and old versions of Pin will work with new binaries in XONLY mode.  This seems like an appropriate tradeoff for Fedora, and it's the upstream kernel default.


Note You need to log in before you can comment on or make changes to this bug.