Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 21 May 2014 14:52:55 -0700 | Subject | Re: [RFC] x86_64: A real proposal for iret-less return to kernel |
| |
On Wed, May 21, 2014 at 2:48 PM, Borislav Petkov <bp@alien8.de> wrote: > On Wed, May 21, 2014 at 02:35:59PM -0700, Andy Lutomirski wrote: >> If RIPV is set but we interrupted *kernel* code, SIGBUS doesn't seem >> like the right solution anyway. >> >> Are there any machine check exceptions for which it makes sense to >> continue right where we left off without a signal? Is CMIC such a >> beast? Can CMIC be delivered when interrupts are off? > > I think you mean CMCI and that's not even reported with a MCE exception > - there's a separate APIC interrupt for that. > > I think this signal thing is for killing processes which have poisoned > memory but this memory can contained within that process and the > physical page frame can be poisoned so that it doesn't get used ever > again. In any case, this is an example for an uncorrectable error which > needs action from us but doesn't necessarily have to kill the whole > machine. > > This is supposed to be more graceful instead of consuming the corrupted > data and sending it out to disk. > > But sending signals from #MC context is definitely a bad idea. I think > we had addressed this with irq_work at some point but my memory is very > hazy.
Why is it a problem if user_mode_vm(regs)? Conversely, why is sending a signal a remotely reasonable thing to do if !user_mode_vm(regs)?
--Andy
| |