Tags Tags

[3.1 patch] x86: default to vsyscall=native

October 05th, 2011 - 05:50 pm ET by Adrian Bunk | Report spam
Help Create a new topic
After upgrading a kernel the existing userspace should just work
(assuming it did work before ;-) ), but when I upgraded my kernel
from 3.0.4 to 3.1.0-rc8 a UML instance didn't come up properly.

dmesg said:
linux-2.6.30.1[3800] vsyscall fault (exploit attempt?) ip:ffffffffff600000 cs:33 sp:7fbfb9c498 ax:ffffffffff600000 si:0 di:606790
linux-2.6.30.1[3856] vsyscall fault (exploit attempt?) ip:ffffffffff600000 cs:33 sp:7fbfb13168 ax:ffffffffff600000 si:0 di:606790

Looking throught the changelog I ended up at commit 3ae36655
("x86-64: Rework vsyscall emulation and add vsyscall= parameter").

Linus suggested in https://lkml.org/lkml/2011/8/9/376 to default to
vsyscall=native.

That sounds reasonable to me, and fixes the problem for me.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Andrew Lutomirski <luto@mit.edu>

Documentation/kernel-parameters.txt | 7 ++++
arch/x86/kernel/vsyscall_64.c | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 854ed5ca..d6e6724 100644
a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2706,10 +2706,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
functions are at fixed addresses, they make nice
targets for exploits that can control RIP.

- emulate [default] Vsyscalls turn into traps and are
- emulated reasonably safely.
+ emulate Vsyscalls turn into traps and are emulated
+ reasonably safely.

- native Vsyscalls are native syscall instructions.
+ native [default] Vsyscalls are native syscall
+ instructions.
This is a little bit faster than trapping
and makes a few dynamic recompilers work
better than they would in emulation mode.
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 18ae83d..b56c65de 100644
a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -56,7 +56,7 @@ DEFINE_VVAR(struct vsyscall_gtod_data, vsyscall_gtod_data) .lock = __SEQLOCK_UNLOCKED(__vsyscall_gtod_data.lock),
};

-static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE;
+static enum { EMULATE, NATIVE, NONE } vsyscall_mode = NATIVE;

static int __init vsyscall_setup(char *str)
{
1.7.6.3

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

Similar topics

Display all similar topics

Replies

#1 Thomas Gleixner
October 05th, 2011 - 06:10 pm ET | Report spam
On Thu, 6 Oct 2011, Adrian Bunk wrote:

After upgrading a kernel the existing userspace should just work
(assuming it did work before ;-) ), but when I upgraded my kernel
from 3.0.4 to 3.1.0-rc8 a UML instance didn't come up properly.

dmesg said:
linux-2.6.30.1[3800] vsyscall fault (exploit attempt?) ip:ffffffffff600000 cs:33 sp:7fbfb9c498 ax:ffffffffff600000 si:0 di:606790
linux-2.6.30.1[3856] vsyscall fault (exploit attempt?) ip:ffffffffff600000 cs:33 sp:7fbfb13168 ax:ffffffffff600000 si:0 di:606790

Looking throught the changelog I ended up at commit 3ae36655
("x86-64: Rework vsyscall emulation and add vsyscall= parameter").

Linus suggested in https://lkml.org/lkml/2011/8/9/376 to default to
vsyscall=native.

That sounds reasonable to me, and fixes the problem for me.



NAK.

We have way too long listened to people who insisted that we keep all
known security holes open by default for the sake of backwards
compatibility.

Default wants to be restricted and not the other way round. Forcing
people to loosen restrictions makes them aware of the problem. Not
doing so keeps them in the illusion that stuff is just safe to use.

We might need better dmesg output, e.g.

printk_once("you might run something which requires
vsyscall=native, but be aware that you are
opening a security hole. See Documentation/")

That's fine, but making the defaults insecure is just ass backwards.

Thanks,

tglx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#2 Adrian Bunk
October 09th, 2011 - 09:50 am ET | Report spam

At least some UML versions run into this and need vsyscall=native
for now.

Signed-off-by: Adrian Bunk

arch/x86/kernel/vsyscall_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 18ae83d..4ab7e32 100644
a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -206,7 +206,7 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
* vsyscalls harder, generate SIGSEGV here as well.
*/
warn_bad_vsyscall(KERN_INFO, regs,
- "vsyscall fault (exploit attempt?)");
+ "vsyscall fault (exploit attempt?) - if this is a legitimate program boot with vsyscall=native (read kernel-parameters.txt for the security implications)");
goto sigsegv;
}





To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Replies Reply to this message
#3 Adrian Bunk
October 09th, 2011 - 09:50 am ET | Report spam
On Thu, Oct 06, 2011 at 12:01:44AM +0200, Thomas Gleixner wrote:
...
We might need better dmesg output, e.g.

printk_once("you might run something which requires
vsyscall=native, but be aware that you are
opening a security hole. See Documentation/")

That's fine, but making the defaults insecure is just ass backwards.



Better dmesg output is in any case a better idea, patch is coming.

I stayed with warn_bad_vsyscall() instead of printk_once() for
the following reasons:
- _once is bad for something that might indicate exploit attempts,
warn_bad_vsyscall() is already ratelimited
- the name and pid of the process should be shown
- the additional output of warn_bad_vsyscall() can help determine
what caused it

Thanks,

tglx



cu
Adrian


"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search