Il 28/04/2014 16:01, Kevin O'Connor ha scritto:
> OVMF probably wants set aside some ram which can't be accessed by the
> OS, for secure boot emulation which is actually secure. Guess we'll
> just go map/unmap some slot in the smm enter/leave vmexits? Or there
> are better ways to do it?
Normally, the memory at 0xa0000-0xc0000 is only mapped when in SMM.
Yes, and there's also a configuration space bit that lets you show/hide
SMRAM at 0xa0000-0xc0000. Another a configuration space bit that lets
you lock the first bit. QEMU doesn't implement the lock, but it should
not be hard.
For OVMF, we would certainly lock SMRAM out. For SeaBIOS, if we can
avoid that it would help writing testcases... SeaBIOS is not doing
anything security-sensitive in SMM anyway.
And, as I understand it, in a multi-cpu system only the core handling
the SMI can access that ram. (All other cores would continue to
access IO space at 0xa0000-0xc0000.)
QEMU just grew per-CPU address spaces, but not KVM.
I don't think we need it. For SeaBIOS's callbacks we can assume single
processor, SeaBIOS is not thread-safe anyway. And the only interaction
would be with legacy VGA VRAM, so no big deal.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
