On Sat, 2013-03-02 at 00:07 +0100, Borislav Petkov wrote: > Hmm, yeah, that's nasty. This also means option #2 can go too because > of the fixed addresses. Option #1 is also kinda polluting user address > space User address space is there to be polluted. Create a "kernel thread" for invoking EFI, except that this kernel thread actually has userspace page tables. Set up those page tables however the hell you like, and then just make sure you always invoke EFI runtime services from that thread. > so maybe the most elegant one would be #4, AFAICT. > > We just need a nice mechanism to tell those mappings to the kexec-d > kernel and when it starts, to establish them right away. Well, there's a *shitload* of things we already need to hand off to the kexec'd kernel that we don't. We don't pass the EFI system table, which means that even the ACPI tables aren't found by the child kernel. And all of the setup_data is missing. And there's probably more. I was looking at this, but there was *other* breakage with kexec which was being sorted out at the time, and I kind of got distracted into doing CSM support in SeaBIOS. The other option, for the long term, is to fix the damn firmware to allow SetVirtualAddressMap to be called more than once. It was stupid for it to be a one-time call anyway. I have a test build of OVMF here which does just that, but haven't got round to testing it yet. I wish I'd been given the *patch* not just a binary though... -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
