lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 6 Oct 2011 00:01:44 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Adrian Bunk <bunk@...sta.de>
cc:	Andrew Lutomirski <luto@....edu>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm00@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [3.1 patch] x86: default to vsyscall=native

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ