On 26 July 2018 at 20:09, Andy Lutomirski <[email protected]> wrote: > [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. >
The main problem is that we have just merged Sai's code to use a work queue for invoking EFI services, and killing kworker threads is obviously not going to make EFI any new friends. So I guess we should probably rework that code to use a dedicated kthread, and just freeze it when it performs an illegal memory access, and signal the completion in a way that makes the calling thread understand that a) the call failed and b) runtime services are no longer available. -- 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
