All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Valdis.Kletnieks@vt.edu
Cc: Andrew 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>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	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>
Subject: Re: [PATCH v3 10/10] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule
Date: Thu, 2 Jun 2011 10:09:37 +0200	[thread overview]
Message-ID: <20110602080937.GA5722@elte.hu> (raw)
In-Reply-To: <13093.1306952865@turing-police.cc.vt.edu>


* Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:

> On Wed, 01 Jun 2011 13:41:56 EDT, Andrew Lutomirski said:
> 
> >> +         On a system with recent enough glibc (probably 2.14 or
> >>  +         newer) and no static binaries, you can say N without a
> >>  +         performance penalty to improve security
> >>
> >> So I checked my laptop (Fedora 16 Rawhide), and found a bunch of static binaries. The ones
> >> that look like people may care:
> 
> > The binaries will still work -- they'll just take a small performance
> > hit (~220ns on Sandy Bridge) every time they call time().
> 
> Ah. I misparsed the Kconfig help - I read it as "If you have no 
> static binaries, setting this to N doesn't introduce a performance 
> hit" (with an implied "if you have static binaries, this will hose 
> you").  Adding "Static binaries will continue to work at a very 
> small performance penalty" would probably help.

Yeah, would be nice to add that clarification. (or better yet, 
reformulate it in a way that makes it really obvious from the get 
go.)

Thanks,

	Ingo

  reply	other threads:[~2011-06-02  8:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-31 13:15 [PATCH v3 00/10] Remove syscall instructions at fixed addresses Andy Lutomirski
2011-05-31 13:15 ` [PATCH v3 01/10] x86-64: Fix alignment of jiffies variable Andy Lutomirski
2011-05-31 13:15 ` [PATCH v3 02/10] x86-64: Document some of entry_64.S Andy Lutomirski
2011-05-31 13:15 ` [PATCH v3 03/10] x86-64: Give vvars their own page Andy Lutomirski
2011-05-31 13:15 ` [PATCH v3 04/10] x86-64: Remove kernel.vsyscall64 sysctl Andy Lutomirski
2011-05-31 13:15 ` [PATCH v3 05/10] x86-64: Map the HPET NX Andy Lutomirski
2011-05-31 13:16 ` [PATCH v3 06/10] x86-64: Remove vsyscall number 3 (venosys) Andy Lutomirski
2011-05-31 13:16 ` [PATCH v3 07/10] x86-64: Fill unused parts of the vsyscall page with 0xcc Andy Lutomirski
2011-05-31 13:16 ` [PATCH v3 08/10] x86-64: Emulate legacy vsyscalls Andy Lutomirski
2011-06-01 11:54   ` Brian Gerst
2011-06-01 12:36     ` Andrew Lutomirski
2011-05-31 13:16 ` [PATCH v3 09/10] x86-64: Randomize int 0xcc magic al values at boot Andy Lutomirski
2011-05-31 13:16 ` [PATCH v3 10/10] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule Andy Lutomirski
2011-06-01 17:35   ` Valdis.Kletnieks
2011-06-01 17:41     ` Andrew Lutomirski
2011-06-01 18:27       ` Valdis.Kletnieks
2011-06-02  8:09         ` Ingo Molnar [this message]
2011-05-31 13:45 ` [PATCH v3 00/10] Remove syscall instructions at fixed addresses Ingo Molnar
2011-05-31 13:54   ` Andrew Lutomirski
  -- strict thread matches above, loose matches on Subject: below --
2011-05-31 14:13 [PATCH v4 " Andy Lutomirski
2011-05-31 14:14 ` [PATCH v4 10/10] x86-64: Add CONFIG_UNSAFE_VSYSCALLS to feature-removal-schedule Andy Lutomirski
2011-05-31 18:34   ` Andi Kleen
2011-05-31 18:59     ` Andrew Lutomirski
2011-05-31 19:28       ` Ingo Molnar
2011-05-31 19:36         ` Ingo Molnar
2011-08-06 20:18           ` [PATCH v3 " 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=20110602080937.GA5722@elte.hu \
    --to=mingo@elte.hu \
    --cc=JBeulich@novell.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=bp@alien8.de \
    --cc=jj@chaosbits.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mikpe@it.uu.se \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.