public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Kevin O'Connor" <kevin@koconnor.net>, Gerd Hoffmann <kraxel@redhat.com>
Cc: kvm-devel <kvm@vger.kernel.org>, Laszlo Ersek <lersek@redhat.com>
Subject: Re: kvm smm mode support?
Date: Mon, 28 Apr 2014 16:22:34 +0200	[thread overview]
Message-ID: <535E642A.7040806@redhat.com> (raw)
In-Reply-To: <20140428140102.GA7576@morn.localdomain>

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

  reply	other threads:[~2014-04-28 14:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25  7:39 kvm smm mode support? Gerd Hoffmann
2014-04-26  9:40 ` Paolo Bonzini
2014-04-26 11:02   ` Paolo Bonzini
2014-04-28 13:49     ` Gerd Hoffmann
2014-04-28 14:01       ` Kevin O'Connor
2014-04-28 14:22         ` Paolo Bonzini [this message]
2014-04-28 13:40   ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=535E642A.7040806@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lersek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox