Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes

[Suresh Siddha]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/