Messages in this thread Patch in this message |  | | | From | Andy Lutomirski <> | | Subject | [PATCH 4/4] Add vsyscalls to feature-removal-schedule.txt | | Date | Tue, 9 Aug 2011 10:27:50 -0400 |
| |
In a couple years, we'll see how well we've done at eradicating vsyscall-using binaries. Hopefully we can then disable them by default. We will probably have to leave the option to enable them around forever.
Signed-off-by: Andy Lutomirski <luto@mit.edu> --- Documentation/feature-removal-schedule.txt | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 43f4809..981562f 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -575,6 +575,20 @@ Who: Hans Verkuil <hans.verkuil@cisco.com> ---------------------------- +What: vsyscalls may go away by default +When: 3.6 +Why: All vsyscall functionality is available as regular syscalls and through + the vDSO. Vsyscalls are currently emulated and are slower than normal + syscalls. Userspace exploits can still use the emulated vsyscall traps + as a form of 'ret' instruction. + + In the mean time, do *not* rely on the semantics of int 0x40, int 0x41, + and int 0x42. They may change or go away completely with no notice. + Any attempt to use them will result in a warning in the kernel log. +Who: Andy Lutomirski <luto@mit.edu> + +---------------------------- + What: g_file_storage driver When: 3.8 Why: This driver has been superseded by g_mass_storage. -- 1.7.6
|  |