Messages in this thread | | | From | Wolfgang Walter <> | Subject | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes | Date | Sun, 10 Aug 2008 00:59:10 +0200 |
| |
On Saturday 09 August 2008, Suresh Siddha wrote: > 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(); > ... > >
The first solution - if it works and padlock is the only which has problem with it - seems to be a good fix for 2.6.26. If it works I can't say as I'm not familiar enough with these things. But I'll happily test it :-).
The second would be a little bit intrusive, wouldn't it? Most machines don't have padlock, and therfore don't need this change but nevertheless may be affected (i.e. they use MMX for memcpy or MMX/SSE with raid6) and now get a different behaviour. Don't know how expensive such a local_irq_enable/disable would be.
Regards, -- Wolfgang Walter Studentenwerk München Anstalt des öffentlichen Rechts -- 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/
| |