LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: pageexec@freemail.hu
To: Ingo Molnar <mingo@elte.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 20:55:20 +0200	[thread overview]
Message-ID: <47B4AAB8.106.FEA5232@pageexec.freemail.hu> (raw)
In-Reply-To: <20080214190050.GA32258@elte.hu>

On 14 Feb 2008 at 20:00, Ingo Molnar wrote:

> > the best practical defense against leaking the canary is to change its 
> > value on every syscall but it has some performance impact in 
> > microbenchmarks.
> 
> yeah, that's not really practical (especially as it would deplete our 
> entropy pool pretty fast would could in some circumstances introduce a 
> higher risk to the system than the risk of a canary leaking).

you don't necessarily have to use the heavy-handed ip id code as it
is used now, random32 is plenty good here.

> I think we can avoid the leakage across tasks by being careful during 
> context-switch time: never calling with the old canary still in the PDA. 
> I think this should be fairly easy as we'd just have to load the new 
> pdaptr in the switch_to() assembly code.

i don't think you have to worry about cross-task leaking at all, a
hypothetical exploit is happy to learn its own canary and that's
actually easier than learning some other task's canary by virtue
of bugs that leak uninitialized struct padding and stuff...

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 ;).

> 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.


  reply	other threads:[~2008-02-14 19:56 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 [this message]
2008-02-14 20:25       ` Ingo Molnar
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=47B4AAB8.106.FEA5232@pageexec.freemail.hu \
    --to=pageexec@freemail.hu \
    --cc=arjan@infradead.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.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).