Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753191AbYHIThk (ORCPT ); Sat, 9 Aug 2008 15:37:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751914AbYHITha (ORCPT ); Sat, 9 Aug 2008 15:37:30 -0400 Received: from mga11.intel.com ([192.55.52.93]:51841 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751892AbYHITh3 (ORCPT ); Sat, 9 Aug 2008 15:37:29 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.31,334,1215414000"; d="scan'208";a="369207244" Date: Sat, 9 Aug 2008 12:37:24 -0700 From: Suresh Siddha To: "Siddha, Suresh B" Cc: "H. Peter Anvin" , Wolfgang Walter , Herbert Xu , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ingo Molnar , "viro@ZenIV.linux.org.uk" , "vegard.nossum@gmail.com" Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes Message-ID: <20080809193724.GJ13158@linux-os.sc.intel.com> References: <200807171653.59177.wolfgang.walter@stwm.de> <20080808231121.GA13158@linux-os.sc.intel.com> <20080809143727.GA30499@gondor.apana.org.au> <200808091757.32999.wolfgang.walter@stwm.de> <489DC15D.9070308@zytor.com> <20080809185224.GH13158@linux-os.sc.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080809185224.GH13158@linux-os.sc.intel.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1329 Lines: 53 On Sat, Aug 09, 2008 at 11:52:24AM -0700, Siddha, Suresh B wrote: > Backing out lazy allocation is not just enough here. Let me think a little > more on this. Can we have something like irq_ts_save() and irq_ts_restore(), which will do something like: int irq_ts_save() { if (!in_interrupt()) return 0; if (read_cr0() & X86_CR0_TS) { clts(); return 1; } return 0; } void irq_ts_restore(int TS_state) { if (!in_interrupt()) return 0; if (TS_state) stts(); } and use this around padlock usage. Taking a spurious DNA fault in the process context(even inside the kernel) should be ok. Main issue is with the interrupt context and we can prevent the DNA fault in the irq context using above. Either above, or we have to remove the lazy fpu allocation and make the below code in kernel_fpu_begin() atomic by disabling interrupts(to fix the security hole with padlock usage) kernel_fpu_begin: ... local_irq_disable(); if (me->status & TS_USEDFPU) __save_init_fpu(me->task); else clts(); local_irq_enable(); ... -- 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/