On 09/22/2010 06:16 PM, Kevin O'Connor wrote:
Using SMI is something I've thought a little about. It does have some snags: SMI programming is chipset specific on real hardware so one can't deploy a single solution for all coreboot users; kvm doesn't have SMI support;
Right so far, althoguh SMI is pretty easy to implement.
using an SMI to get out of vm86 mode requires the BIOS to emulate all memory accesses to user memory (manually walking the page table, forcing page faults) which is tricky;
Actually you can switch to protected mode and turn the page tables on if you want.
there might be subtle security implications with having a BIOS interface that can effectively escalate privileges.
Yes.
The other option is to enter protected mode for the operation, or, if you detect that you're already in protected mode (which means V86 mode)
I didn't think there was a way for the user code to know it was running in vm86 mode - I thought it appeared just like regular real-mode. One could try to go into protected mode and try to catch the failure, but I'd guess most OSs that run code in vm86 mode would trap and abort in that situation.
No, the SMSW instruction can be used to distinguish protected mode and therefore V86 mode.
then you invoke the INT 15h mover. Not all environments is going to handle the INT 15h mover correctly, though.
Are you referring to INT 0x15 ah=0x89? This can request a transition to protected mode, but I didn't see any equivalent way to get back to real mode.
No, AH=0x87.
A related call is INT 0x15 ah=0x87 which does a highmem capable memcpy. Unfortunately this handler does a 16bit memcpy (rep movsw), and the OHCI spec requires the cmdstatus register be accessed with a 32bit memory access.
That might be a problem if that is actually done that way (which it generally won't.) Still, you do have the issue of what happens in a V86 environment if it doesn't just pass code to the original BIOS.
-hpa