[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080809193724.GJ13158@linux-os.sc.intel.com>
Date: Sat, 9 Aug 2008 12:37:24 -0700
From: Suresh Siddha <suresh.b.siddha@...el.com>
To: "Siddha, Suresh B" <suresh.b.siddha@...el.com>
Cc: "H. Peter Anvin" <hpa@...or.com>,
Wolfgang Walter <wolfgang.walter@...m.de>,
Herbert Xu <herbert@...dor.apana.org.au>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
"viro@...IV.linux.org.uk" <viro@...iv.linux.org.uk>,
"vegard.nossum@...il.com" <vegard.nossum@...il.com>
Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists