[sorry for totally busted formatting -- your email client and Gmail don't get along]
On Jul 26, 2018, at 10:23 AM, Prakhya, Sai Praneeth <[email protected]> wrote: > I have added some x86/intel folks to cc. > > I am fine with these patches, and I think it is useful to be able to > detect and recover from buggy UEFI implementations that use boot time > regions at runtime. > > However, I need help from the x86 maintainers/developers to review > this so please cc them on these patches. > > > > I'm okay with the general concept, but I'm not really thrilled by the > longjmp-like approach. > > > > Wasn't there a bunch of talk of having an actual kernel thread (kefid?) that > makes runtime services calls? Did that actually get implemented? IMO a much > nicer approach would be to handle the page fault by killing the thread, more > or less like how we kill unruly user threads. (And it's yet another step > toward calling EFI runtime services at CPL 3!) > > > > Hi Andy, > > > > Thanks for the feedback J. > > > > We have efi_kthread implemented and I did briefly think about killing the > efi_kthread approach, but I thought it might not be possible (I might be > wrong) because, we are in page fault handler and if we kill efi_kthread, the > page fault handler still returns to firmware (because a firmware instruction > caused page fault) and firmware will try to perform illegal access again > thinking that the page fault handler might have fixed the fault. So, I took > this approach of jumping out of firmware. > > > > Please let me know If you think I missed something. The basic idea is that, when you get an exception from a context that is busted (i.e. it wasn't user code with a signal handler or kernel code with a fixup), you can't return from the exception handler. That leaves two choices: 1. Kill the task without returning. You could call do_exit(), or, roughly equivalently, let yourself OOPS (fall through to die(), etc). Then you have to make sure that the code that called into the thread can handle it by signaling some completion first or whatever you need to do. 2. Sleep forever. For example, set the task state to TASK_UNINTERRUPTIBLE and reschedule. If the thread is a real kthread, (1) may be a bad idea. I’m not sure a kthread can tolerate do_exit(), since the kthread core plays awful games involving storing important data structures on the stack. Also, with (2), it might be possible to enable some after-the-fact debugging, since the full crashing state is still there. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
