On Thu, Sep 22, 2016 at 01:58:54PM +0100, Mark Rutland wrote: > On Thu, Sep 22, 2016 at 12:30:03PM +0100, Ard Biesheuvel wrote: > > This series proposes an approach to work around this. It implements the UEFI > > MMC host protocol in the kernel, in a way that makes it possible to expose it > > to the firmware. At the same time, the firmware needs be set up for this, i.e., > > it needs to expose its MMC host protocol pointer via a UEFI configuration table, > > so that the kernel can override it if it decides to expose this functionality > > to the firmware. > > At a high level, and assuming a number of details from previous > discussions, I think the general approach of having the kernel mediate > access to the MMC makes sense. > I have a few other general concerns: Another few thoughts I had: * The UEFI spec mandates that a certain amount of stack space is available to runtime services which we call. If UEFI can call back into the kernel, it's not clear how much of the stack is available to either UEFI or the kernel. This is a rather fragile area -- kernel stack usage can vary wildly depending on configuration options. * CPU state management. Runtime services can temporarily mask interrupts, and may require interrupts to remain masked over calls back into the kernel. That and other concerns mean that deadlock is going to be very difficult to avoid. * It gets in the way of (though doesn't strictly prevent) sandboxing. One thing I'd like to do is run UEFI services in a more restricted environment (e.g. a VM if we have EL2 available), to aid robustness and debugging. Having a single entry/exit point, and not having to proxy calls would make this far simpler. Overall, I'd far prefer that we have a strict one-way call policy (as is the case today with UEFI), even if that means we have to make a number of calls to achieve some functionality. In addition to the above, that also sidesteps the lifetime issues I mentioned previously (modulo some FW-side state retained across kexec and so on). Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
