Bug 1876977

Summary: Please change the vsyscall config to CONFIG_LEGACY_VSYSCALL_XONLY
Product: [Fedora] Fedora Reporter: Andy Lutomirski <luto>
Component: kernelAssignee: Herton R. Krzesinski <hkrzesin>
Status: POST --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: acaringi, airlied, bskeggs, fweimer, hdegoede, hkrzesin, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, mjg59, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.