[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Apr 2013 03:40:33 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Ingo Molnar <mingo@...nel.org>
Cc: "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>, Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Jeremy Fitzhardinge <jeremy@...p.org>, Marcelo Tosatti <mtosatti@...hat.com>, Alex Shi <alex.shi@...el.com>, Borislav Petkov <borislav.petkov@....com>, Alexander Duyck <alexander.h.duyck@...el.com>, Frederic Weisbecker <fweisbec@...il.com>, Steven Rostedt <rostedt@...dmis.org>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, xen-devel@...ts.xensource.com, virtualization@...ts.linux-foundation.org, kernel-hardening@...ts.openwall.com, Dan Rosenberg <drosenberg@...curity.com>, Julien Tinnes <jln@...gle.com>, Will Drewry <wad@...omium.org>, Eric Northup <digitaleric@...gle.com>
Subject: Re: [PATCH] x86: make IDT read-only
Ingo Molnar <mingo@...nel.org> writes:
> * Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
>> "H. Peter Anvin" <hpa@...or.com> writes:
>>
>> > On 04/08/2013 03:43 PM, Kees Cook wrote:
>> >> This makes the IDT unconditionally read-only. This primarily removes
>> >> the IDT from being a target for arbitrary memory write attacks. It has
>> >> an added benefit of also not leaking (via the "sidt" instruction) the
>> >> kernel base offset, if it has been relocated.
>> >>
>> >> Signed-off-by: Kees Cook <keescook@...omium.org>
>> >> Cc: Eric Northup <digitaleric@...gle.com>
>> >
>> > Also, tglx: does this interfere with your per-cpu IDT efforts?
>>
>> Given that we don't change any IDT entries why would anyone want a
>> per-cpu IDT? The cache lines should easily be shared accross all
>> processors.
>
> That's true iif they are cached.
>
> If not then it's a remote DRAM access cache miss for all CPUs except the node that
> holds that memory.
>
>> Or are there some giant NUMA machines that trigger cache misses when accessing
>> the IDT and the penalty for pulling the cache line across the NUMA fabric is
>> prohibitive?
>
> IDT accesses for pure userspace execution are pretty rare. So we are not just
> talking about huge NUMA machines here but about ordinary NUMA machines taking a
> remote cache miss hit for the first IRQ or other IDT-accessing operation they do
> after some cache-intense user-space processing.
>
> It's a small effect, but it exists and improving it would be
> legitimate.
If the effect is measurable I agree it is a legitimate optimization. At
one point there was a suggestion to make the code in the IDT vectors
differ based on the which interrupt was registed. While that can also
reduce cache misses that can get hairy very quickly, and of course that
would require read-write IDTs.
My only practical concern with duplicating the IDT tables per cpu is (a)
there are generic idt handlers that remain unduplicated reducing the
benefit and this is essentially the same optimization as making the
entire kernel text per cpu which last time it was examined was not an
optimization worth making. So I wonder if just a subset of the
optimization is worth making.
Eric
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
