[PATCH 4/4] Add vsyscalls to feature-removal-schedule.txt

From: Andy Lutomirski
Date: Tue Aug 09 2011 - 10:28:32 EST

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@xxxxxxx>
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@xxxxxxxxx>


+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@xxxxxxx>
What: g_file_storage driver
When: 3.8
Why: This driver has been superseded by g_mass_storage.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/