LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: pageexec@freemail.hu
Cc: Sam Ravnborg <sam@ravnborg.org>,
	Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, torvalds@linux-foundation.org,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [x86.git#mm] stack protector fixes, vmsplice exploit
Date: Thu, 14 Feb 2008 21:25:35 +0100	[thread overview]
Message-ID: <20080214202535.GA25316@elte.hu> (raw)
In-Reply-To: <47B4AAB8.106.FEA5232@pageexec.freemail.hu>


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

> really, the best defense is to reduce the useful lifetime of any 
> leaked canary, and you can't get better than syscall granularity 
> without disproportional effort and impact elsewhere (and i'm sure some 
> would find even this disproportional ;).

hm, i think per syscall canaries are really expensive.

The per function call overhead from stackprotector is already pretty 
serious IMO, but at least that's something that GCC _could_ be doing 
(much) smarter (why doesnt it jne forward out to __check_stk_failure, 
instead of generating 4 instructions, one of them a default-mispredicted 
branch instruction??), so that overhead could in theory be something 
like 4 fall-through instructions per function, instead of the current 6.

Also, even with -fstack-protector-all, gcc could detect the _provably_ 
correct and overflow-safe functions and skip their annotation 
altogether. And those are the ones that hurt most: the small and 
straightforward (and also, most of the time, overflow-free) ones.

The heuristics for -fstack-protector were really botched, as you noted 
they happened to mark vmsplice as "safe". So either we do the full thing 
or nothing - anything inbetween is just russian roulette and false sense 
of security.

But per syscall canary randomization is something that would be a drag 
on our null syscall latency forever. I'm really unsure about it. It will 
also be driven in the wrong direction: people would try to "optimize" 
the per syscall random number generation which is a constant erosive 
force on its strength and there's no strong counter-force. (and no clear 
boundary either 'random32 should be plenty enough' is too vague as 
limit.)

So lets perhaps also analyze the security effects of not having per 
system call canaries and make the best out of it: the main threat is 
information leaks via padding and similar initialization mistakes [which 
have almost zero accidental discovery rate], right?

So could we perhaps somehow turn kernel-space information leaks into 
functional, and hence detectable failures? Wouldnt for example kmemcheck 
notice them, once they are copied to user-space? [ If you havent seen 
kmemcheck yet i think you'll love it, it's a similarly neat trick as the 
pte noexec trick you did in the PaX kernel. It's similarly disgusting as 
well ;-) ]

> > TODO: perhaps all vsyscall functions need to move into separate .o 
> > files. (probably academic as the functions affected by that tend to 
> > be very simple and do not deal with anything overflowable.)
> 
> yeah, i wasn't suggesting it for its security value, more like for 
> 'full coverage'. if such a separation isn't useful otherwise (no idea 
> if not having the .vsyscall* code along with related kernel code would 
> be confusing for the reader for example), i'd say this isn't 
> important.

perhaps it would be more useful to have some "no stack protector" gcc 
attribute. We could then stick that into the __vsyscall definition and 
it's all done and self-maintaining from that point on. (because a 
missing __vsyscall annotation results in a runtime failure.) (I'd fully 
expect GCC to not have provided such an attribute.)

but yes, i agree in general that it's easier to maintain something if 
it's full coverage, that way one does not have to keep in mind (and 
cannot accidentally forget ;-) the exceptions.

	Ingo

  reply	other threads:[~2008-02-14 20:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-14 17:00 Ingo Molnar
2008-02-14 17:16 ` pageexec
2008-02-14 19:00   ` Ingo Molnar
2008-02-14 18:55     ` pageexec
2008-02-14 20:25       ` Ingo Molnar [this message]
2008-02-14 21:00         ` Arjan van de Ven
2008-02-14 21:12         ` pageexec
2008-02-14 22:35         ` Jakub Jelinek
2008-02-14 21:43           ` pageexec
2008-02-14 23:19             ` Ingo Molnar
2008-02-14 23:16           ` Ingo Molnar

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=20080214202535.GA25316@elte.hu \
    --to=mingo@elte.hu \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pageexec@freemail.hu \
    --cc=sam@ravnborg.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: [x86.git#mm] stack protector fixes, vmsplice exploit' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).