Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936514Ab3DHXAH (ORCPT ); Mon, 8 Apr 2013 19:00:07 -0400 Received: from mail-oa0-f43.google.com ([209.85.219.43]:58219 "EHLO mail-oa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936202Ab3DHXAF (ORCPT ); Mon, 8 Apr 2013 19:00:05 -0400 MIME-Version: 1.0 In-Reply-To: References: <20130408224328.GA17641@www.outflux.net> Date: Mon, 8 Apr 2013 16:00:04 -0700 X-Google-Sender-Auth: txWKUZzv6qYzTO1m4ENagqpGk6M Message-ID: Subject: Re: [PATCH] x86: make IDT read-only From: Kees Cook To: "Maciej W. Rozycki" Cc: Ingo Molnar , LKML , Thomas Gleixner , "H. Peter Anvin" , "x86@kernel.org" , Konrad Rzeszutek Wilk , Jeremy Fitzhardinge , Marcelo Tosatti , Alex Shi , Borislav Petkov , Alexander Duyck , Frederic Weisbecker , Steven Rostedt , "Paul E. McKenney" , "xen-devel@lists.xensource.com" , "virtualization@lists.linux-foundation.org" , "kernel-hardening@lists.openwall.com" , Dan Rosenberg , Julien Tinnes , Will Drewry , Eric Northup Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1761 Lines: 40 On Mon, Apr 8, 2013 at 3:56 PM, Maciej W. Rozycki wrote: > On Mon, 8 Apr 2013, 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. > [...] >> --- a/arch/x86/kernel/cpu/intel.c >> +++ b/arch/x86/kernel/cpu/intel.c >> @@ -215,7 +201,6 @@ static void __cpuinit intel_workarounds(struct cpuinfo_x86 *c) >> >> c->f00f_bug = 1; >> if (!f00f_workaround_enabled) { >> - trap_init_f00f_bug(); >> printk(KERN_NOTICE "Intel Pentium with F0 0F bug - workaround enabled.\n"); >> f00f_workaround_enabled = 1; >> } > > FWIW the change looks reasonable to me, however given that that it makes > the arrangement unconditional and there is no longer a workaround to > enable I think it would make sense to remove the conditional block quoted > above altogether, along with the f00f_workaround_enabled variable itself > (alternatively "Intel Pentium with F0 0F bug" alone could be printed > instead and the name of the variable adjusted to make sense with the new > meaning -- up to you to decide). Ah, yes, I misread this and didn't see that the ifdef ended 2 lines further down. :) I'll just remove the entire section of code. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/