Bug 835935 - document a change in the vsyscalls in the v3.2 kernels
document a change in the vsyscalls in the v3.2 kernels
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Release_Notes (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: 2.2
: ---
Assigned To: Tomas Capek
Depends On:
  Show dependency treegraph
Reported: 2012-06-27 10:58 EDT by Beth Uptagrafft
Modified: 2012-09-19 21:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-19 21:01:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Beth Uptagrafft 2012-06-27 10:58:00 EDT
There has been a change in the vsyscalls in the v3.2 kernels which includes the MRG / rt kernels and we think it would be good to alert the customer of this change 

The kernel parameter options are documented in Documentation/kernel-parameters.txt in the vsyscall section.

Vsyscalls are used in many binaries and in some important libraries such as glibc. They allow certain calls such as gettimeofday() to work without changing from user-mode to kernel-mode. This works by having the kernel map memory to user space with read-only values of the current time. This memory also includes native code that emulates the system call, in this case reading the current time and returning the value.

Since this native code is at a fixed address, it could theoretically be used in security exploits. This has now been changed to make it a little more secure by emulating the vsyscalls and removing dangerous instructions from the vsyscall page. The vsyscalls are now emulated by being trapped in the kernel. This emulation occurs without breaking any APIs. It could potentially be slower than the old native code.

This kernel emulation of vsyscalls in the new default and you don't need to do anything to get it. It is also the configuration we have used when testing the MRG kernel.

You can explicitly request it with the kernel parameter. (but this is not necessary)


However, if you want the vsyscalls to operate as they did previously, you can use the kernel parameter

There is also a third option which provides the most security but could break existing binaries and critical libraries such as glibc, so it is not recommended. However, if you think you need it you get it with


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