LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: pageexec@freemail.hu
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andy Lutomirski <luto@mit.edu>,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	linux-kernel@vger.kernel.org, Jesper Juhl <jj@chaosbits.net>,
	Borislav Petkov <bp@alien8.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Jan Beulich <JBeulich@novell.com>,
	richard -rw- weinberger <richard.weinberger@gmail.com>,
	Mikael Pettersson <mikpe@it.uu.se>,
	Andi Kleen <andi@firstfloor.org>, Brian Gerst <brgerst@gmail.com>,
	Louis Rilling <Louis.Rilling@kerlabs.com>,
	Valdis.Kletnieks@vt.edu, Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS
Date: Mon, 6 Jun 2011 21:12:18 +0200
Message-ID: <20110606191218.GB20123@elte.hu> (raw)
In-Reply-To: <4DED16C1.24309.139B86C7@pageexec.freemail.hu>


* pageexec@freemail.hu <pageexec@freemail.hu> wrote:

> On 6 Jun 2011 at 14:47, Ingo Molnar wrote:
> 
> > * pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> > > [...] does that mean that you guys would accept a patch that would 
> > > map the vdso at a fixed address for old times's sake? if not, on 
> > > what grounds would you refuse it? see, you can't have it both ways.
> > 
> > You can actually do that by enabling CONFIG_COMPAT_VDSO=y.

> [...]
> 
> 2. who enables CONFIG_COMPAT_VDSO?
> 
> RHEL? Fedora? SLES? Debian? Ubuntu? (i don't know, i'm asking)

Fedora has not enabled it for a long time.

> and whoever enables them, what do you think they're more likely to 
> get in return? some random and rare old binaries that still run for 
> a minuscule subset of users or every run-of-the-mill exploit 
> working against *every* user, metasploit style (did you know that 
> it has a specific target for the i386 compat vdso)?

That's what binary compatibility means, yes.

> so once again, tell me whether the randomized placement of the vdso 
> wasn't about security (in which case can we please have it back at 
> a fixed mmap'd address, since it doesn't matter for security you 
> have no reason to refuse ;).

It's a statistical security measure, and was such a measure from the 
day it was committed:

 | commit e6e5494cb23d1933735ee47cc674ffe1c4afed6f
 | Author: Ingo Molnar <mingo@elte.hu>
 | Date:   Tue Jun 27 02:53:50 2006 -0700
 |
 |    [PATCH] vdso: randomize the i386 vDSO by moving it into a vma
 |    
 |    Move the i386 VDSO down into a vma and thus randomize it.
 |    
 |    Besides the security implications, this feature also helps debuggers, which
 |    can COW a vma-backed VDSO just like a normal DSO and can thus do
 |    single-stepping and other debugging features.

So what's your point?

> > > the fixed address of the vsyscall page *is* a very real 
> > > security problem, it should have never been accepted as such 
> > > and it's high time it went away finally in 2011AD.
> > 
> > It's only a security problem if there's a security hole 
> > elsewhere.
> 
> it's not an 'if', there *is* a security hole 'elsewhere', else the 
> CVE list had been abandoned long ago and noone would be doing 
> proactive security measures such as intrusion prevention 
> mechanisms.
> 
> so it *is* a security problem.

Two arguments.

Firstly, you generalize too much, it's only a security problem if you 
actually have an attack surface:

  Many Linux systems don't have any: non-networked appliances that 
  are not physically connected to any hostile medium.

  For such a system a gaping root hole bug is *not even a bug*, while 
  a rare memory leak that you'd shrug off on a desktop might be a 
  showstopper.

Secondly, and more importantly, we try to maintain the kernel in a 
way so that it can converge to a no bugs state in the long run.

You can only do that by making sure that even in the very last 
stages, when there are virtually no bugs left, the incentives and 
mechanisms are still there to fix even those bugs.

If we add obstruction features that turn bugs into less severe 
statistical bugs then that automatically reduces the speed of 
convergence.

We might still do it, but you have to see and acknowledge that it's a 
*cost*. You seem to argue that it's a bona fide bug and that the fix 
is deterministic that it "needs fixing" - and that is wrong on both 
counts.

You generally seem to assume that security is an absolute goal with 
no costs attached.

> > The thing is, and i'm not sure whether you realize or recognize 
> > it, but these measures *are* two-edged swords.
> 
> they aren't, see below why.
> 
> > Yes, the upside is that they reduce the risks associated with 
> > security holes - but only statistically so.
> 
> not sure what 'these measures' are here (if you mean ASLR related 
> ones, please say so), some are randomization based (so their impact 
> on security is probabilistic), some aren't (their impact is 
> deterministic).

Which of these changes are deterministic?

Removing a syscall or a RET from a fixed address is *still* only a 
probabilistic fix: the attacker can still do brute-force attacks 
against the many executable pages in user-space, even if everything 
is ASLR obfuscated.

> > The downside is that having such a measure in place makes it 
> > somewhat less likely that those bugs will be found and fixed in 
> > the future:
> 
> i'm not sure i follow you here, it seems to me that you're mixing 
> up bug finding/fixing with exploit development and prevention 
> measures.

It helps if you read the bit i provided after the colon:

  > > if a bug is not exploitable then people like Spender wont spend 
  > > time exploiting and making a big deal out of them, right?

If a bug is hidden via ASLR (and *all* of the changes in this thread 
had only that effect) and can not be exploited using the simple fixed 
address techniques disabled by these patches, then people like you or 
Spender wont spend time exploiting them, right?

But it can still be exploited brute-force: just cycle through the 
possible addresses until you find the right instruction that elevates 
privileges.

> > And yes, it might be embarrasing to see easy exploits and we 
> > might roll eyes at the associated self-promotion circus but it 
> > will be one more bug found, the reasons for the bug will be 
> > examined, potentially avoiding a whole class of similar bugs *for 
> > sure*.
> 
> it's a nice theory, it has never worked anywhere (just look at 
> OpenBSD ;). show me a single class of bugs that you think you'd 
> fixed in linux. [...]

For example after this meta-fix:

  c41d68a: compat: Make compat_alloc_user_space() incorporate the access_ok()

We certainly have eliminated the class of bugs where we'd return 
out-of-bounds pointers allocated via compat_alloc_user_space() and 
exploited via large or negative 'len' values.

> > Can you guarantee that security bugs will be found and fixed with 
> > the same kind of intensity even if we make their exploitation 
> > (much) harder? I don't think you can make such a guarantee.
> 
> why would *i* have to guarantee anything? [...]

It was an generic/indefinite 'you'.

To understand my point you need to look at the context i replied to:

 > > > the fixed address of the vsyscall page *is* a very real 
 > > > security problem, it should have never been accepted as such 
 > > > and it's high time it went away finally in 2011AD.

You claimed that it is a very real security problem. I pointed out 
that this is not a real primary fix for some security bug but a 
statistical method that makes exploits of other bugs harder (but not 
impossible), and as such it has the cost of making *real* fixes 
slower to arrive.

I don't think this was a terribly complicated argument, yet you do 
not even seem to acknowledge that it exists.

Thanks,

	Ingo

  reply index

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-05 17:50 [PATCH v5 0/9] Remove syscall instructions at fixed addresses Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 1/9] x86-64: Fix alignment of jiffies variable Andy Lutomirski
2011-06-06  8:31   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 2/9] x86-64: Document some of entry_64.S Andy Lutomirski
2011-06-06  8:31   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 3/9] x86-64: Give vvars their own page Andy Lutomirski
2011-06-06  8:32   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 4/9] x86-64: Remove kernel.vsyscall64 sysctl Andy Lutomirski
2011-06-06  8:32   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-12-05 18:27   ` [PATCH v5 4/9] " Matthew Maurer
2011-06-05 17:50 ` [PATCH v5 5/9] x86-64: Map the HPET NX Andy Lutomirski
2011-06-06  8:33   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 6/9] x86-64: Remove vsyscall number 3 (venosys) Andy Lutomirski
2011-06-06  8:33   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 7/9] x86-64: Fill unused parts of the vsyscall page with 0xcc Andy Lutomirski
2011-06-06  8:34   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls Andy Lutomirski
2011-06-05 19:30   ` Ingo Molnar
2011-06-05 20:01     ` Andrew Lutomirski
2011-06-06  7:39       ` Ingo Molnar
2011-06-06  9:42       ` pageexec
2011-06-06 11:19         ` Andrew Lutomirski
2011-06-06 11:56           ` pageexec
2011-06-06 12:43             ` Andrew Lutomirski
2011-06-06 13:58               ` pageexec
2011-06-06 14:07                 ` Brian Gerst
2011-06-07 23:32                   ` pageexec
2011-06-07 23:49                     ` Andrew Lutomirski
2011-06-08  6:32                       ` pageexec
2011-06-06 15:26                 ` Ingo Molnar
2011-06-06 15:48                   ` pageexec
2011-06-06 15:59                     ` Ingo Molnar
2011-06-06 16:19                       ` pageexec
2011-06-06 16:47                         ` Ingo Molnar
2011-06-06 22:49                           ` pageexec
2011-06-06 22:57                             ` david
2011-06-07  9:07                               ` Ingo Molnar
2011-06-07  6:59                             ` Pekka Enberg
2011-06-07  8:30                             ` Ingo Molnar
2011-06-07 23:24                               ` pageexec
2011-06-08  5:55                                 ` Pekka Enberg
2011-06-08  6:19                                   ` pageexec
2011-06-08  6:48                                 ` Ingo Molnar
2011-06-08  9:02                                   ` pageexec
2011-06-08  9:11                                     ` Andi Kleen
2011-06-08  9:35                                       ` pageexec
2011-06-08 10:06                                         ` Andi Kleen
2011-06-08 10:26                                           ` pageexec
2011-06-08 10:39                                             ` Ingo Molnar
2011-06-08 10:35                                           ` Ingo Molnar
2011-06-08  9:15                                     ` Ingo Molnar
2011-06-08  7:16                                 ` Ingo Molnar
2011-06-08  9:29                                   ` pageexec
2011-06-06 14:01             ` Linus Torvalds
2011-06-06 14:55               ` pageexec
2011-06-06 15:33                 ` Ingo Molnar
2011-06-06 15:58                   ` pageexec
2011-06-06 15:41         ` Ingo Molnar
2011-06-06  8:34   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-06  8:35   ` [tip:x86/vdso] x86-64, vdso, seccomp: Fix !CONFIG_SECCOMP build tip-bot for Ingo Molnar
2011-06-07  7:49   ` [tip:x86/vdso] x86-64: Emulate legacy vsyscalls tip-bot for Andy Lutomirski
2011-06-07  8:03   ` tip-bot for Andy Lutomirski
2011-06-05 17:50 ` [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule Andy Lutomirski
2011-06-06  8:34   ` [tip:x86/vdso] " tip-bot for Andy Lutomirski
2011-06-06  8:46   ` [PATCH v5 9/9] " Linus Torvalds
2011-06-06  9:31     ` Andi Kleen
2011-06-06 10:39       ` pageexec
2011-06-06 13:56         ` Linus Torvalds
2011-06-06 18:46           ` pageexec
2011-06-06 20:40             ` Linus Torvalds
2011-06-06 20:51               ` Andrew Lutomirski
2011-06-06 21:54                 ` Ingo Molnar
2011-06-06 21:45               ` Ingo Molnar
2011-06-06 21:48                 ` Ingo Molnar
     [not found]                 ` <BANLkTi==uw_h78oaep1cCOCzwY0edLUU_Q@mail.gmail.com>
2011-06-07  8:03                   ` [PATCH, v6] x86-64: Emulate legacy vsyscalls Ingo Molnar
2011-06-06 21:53               ` [PATCH v5 9/9] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule pageexec
2011-06-06 14:44         ` Ingo Molnar
2011-06-06 15:01           ` pageexec
2011-06-06 15:15             ` Ingo Molnar
2011-06-06 15:29               ` pageexec
2011-06-06 16:54                 ` Ingo Molnar
2011-06-06 18:59           ` pageexec
2011-06-06 19:25             ` Ingo Molnar
2011-06-07  0:34               ` pageexec
2011-06-07  9:51                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-10 11:19                     ` Ingo Molnar
2011-06-14  0:48                       ` pageexec
2011-06-15 19:42                         ` Valdis.Kletnieks
2011-06-06 14:52         ` Ingo Molnar
2011-06-06 10:24     ` [PATCH] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS Ingo Molnar
2011-06-06 11:20       ` pageexec
2011-06-06 12:47         ` Ingo Molnar
2011-06-06 12:48           ` Ingo Molnar
2011-06-06 18:04           ` pageexec
2011-06-06 19:12             ` Ingo Molnar [this message]
2011-06-07  0:02               ` pageexec
2011-06-07  9:56                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-09  6:48                     ` Ingo Molnar
2011-06-09 23:33                       ` pageexec
2011-06-07 10:05                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-09  7:02                     ` Ingo Molnar
2011-06-09 23:33                       ` pageexec
2011-06-07 10:13                 ` Ingo Molnar
2011-06-07 23:24                   ` pageexec
2011-06-06 12:19       ` Ted Ts'o
2011-06-06 12:33         ` Andrew Lutomirski
2011-06-06 12:37         ` Ingo Molnar
2011-06-06 14:34     ` [tip:x86/vdso] " tip-bot for Ingo Molnar
2011-06-05 20:05 ` [PATCH v5 0/9] Remove syscall instructions at fixed addresses Andrew Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110606191218.GB20123@elte.hu \
    --to=mingo@elte.hu \
    --cc=JBeulich@novell.com \
    --cc=Louis.Rilling@kerlabs.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=jj@chaosbits.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mikpe@it.uu.se \
    --cc=pageexec@freemail.hu \
    --cc=richard.weinberger@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git