kvm smm mode support?

kvm smm mode support?

[Gerd Hoffmann]

  Hi,

Anyone has plans to add smm support to kvm?

We have two potential use cases meanwhile:

 (1) OVMF could use it to implement the LockBox (storage area the
     OS can't tamper with, needed to make secure boot actually secure).

 (2) SeaBIOS considers using a SMM trampoline to switch into 32bit mode
     for device drivers.  See
        http://www.seabios.org/pipermail/seabios/2014-April/007957.html

cheers,
  Gerd

Re: kvm smm mode support?

[Paolo Bonzini]

Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
> Anyone has plans to add smm support to kvm?

No plans, but it should be a Simple Matter Of Programming...

A good start would be to write unit tests for SMM that work with QEMU. 
Too bad we're late, it could have been a nice summer of code project.

Paolo

> We have two potential use cases meanwhile:
>
>  (1) OVMF could use it to implement the LockBox (storage area the
>      OS can't tamper with, needed to make secure boot actually secure).
>
>  (2) SeaBIOS considers using a SMM trampoline to switch into 32bit mode
>      for device drivers.  See
>         http://www.seabios.org/pipermail/seabios/2014-April/007957.html

Re: kvm smm mode support?

[Paolo Bonzini]

Il 26/04/2014 11:40, Paolo Bonzini ha scritto:
> Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
>> Anyone has plans to add smm support to kvm?
>
> No plans, but it should be a Simple Matter Of Programming...

Well, we need:

- an extra ioctl to inject an SMI (can be modeled after KVM_NMI)

- an extra user exit triggered when SMM is entered or left

- an extra ioctl (or a GET/SET_ONE_REG implementation) to read/write 
whether we are in SMM, used to determine whether the #UD produced by RSM 
should be forwarded to the guest or trigger emulation.

Paolo

> A good start would be to write unit tests for SMM that work with QEMU.
> Too bad we're late, it could have been a nice summer of code project.

Re: kvm smm mode support?

[Laszlo Ersek]

On 04/26/14 11:40, Paolo Bonzini wrote:
> Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
>> Anyone has plans to add smm support to kvm?
> 
> No plans, but it should be a Simple Matter Of Programming...
> 
> A good start would be to write unit tests for SMM that work with QEMU.

Well I don't know what behavior to expect from SMM... :)

Plus, Kevin recently posted some remarks about the SMM implementation in
qemu-tcg -- apparently it's not faithful enough to physical hardware:

http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/7959
http://thread.gmane.org/gmane.comp.emulators.qemu/268909

(But I can see that you've been already discussing the second thread; I
guess I should read up on it first...)

Thanks
Laszlo

Re: kvm smm mode support?

[Gerd Hoffmann]

On Sa, 2014-04-26 at 13:02 +0200, Paolo Bonzini wrote:
> Il 26/04/2014 11:40, Paolo Bonzini ha scritto:
> > Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
> >> Anyone has plans to add smm support to kvm?
> >
> > No plans, but it should be a Simple Matter Of Programming...
> 
> Well, we need:
> 
> - an extra ioctl to inject an SMI (can be modeled after KVM_NMI)
> 
> - an extra user exit triggered when SMM is entered or left
> 
> - an extra ioctl (or a GET/SET_ONE_REG implementation) to read/write 
> whether we are in SMM, used to determine whether the #UD produced by RSM 
> should be forwarded to the guest or trigger emulation.

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?

cheers,
  Gerd

Re: kvm smm mode support?

[Kevin O'Connor]

On Mon, Apr 28, 2014 at 03:49:31PM +0200, Gerd Hoffmann wrote:
> On Sa, 2014-04-26 at 13:02 +0200, Paolo Bonzini wrote:
> > Il 26/04/2014 11:40, Paolo Bonzini ha scritto:
> > > Il 25/04/2014 09:39, Gerd Hoffmann ha scritto:
> > >> Anyone has plans to add smm support to kvm?
> > >
> > > No plans, but it should be a Simple Matter Of Programming...
> > 
> > Well, we need:
> > 
> > - an extra ioctl to inject an SMI (can be modeled after KVM_NMI)
> > 
> > - an extra user exit triggered when SMM is entered or left
> > 
> > - an extra ioctl (or a GET/SET_ONE_REG implementation) to read/write 
> > whether we are in SMM, used to determine whether the #UD produced by RSM 
> > should be forwarded to the guest or trigger emulation.
> 
> 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.
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.)

-Kevin

Re: kvm smm mode support?

[Paolo Bonzini]

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