linux-kernel - Re: [PATCH 08/12] KVM: x86: save/load state on SMM switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150521170014.GB31171@potion.brq.redhat.com>
Date:	Thu, 21 May 2015 19:00:14 +0200
From:	Radim Krčmář <rkrcmar@...hat.com>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org, bsd@...hat.com
Subject: Re: [PATCH 08/12] KVM: x86: save/load state on SMM switch

2015-05-21 18:23+0200, Paolo Bonzini:
> On 21/05/2015 18:20, Radim Krčmář wrote:
>> 2. NMI -> SMI -> IRET -> RSM -> NMI
>> NMI is injected;  I think it shouldn't be ... have you based this
>> behavior on the 3rd paragraph of SDM 34.8 NMI HANDLING WHILE IN SMM
>> ("A special case [...]")?
> 
> Yes.

Well, if I were to go lawyer

 [...] saves the SMRAM state save map but does not save the attribute to
 keep NMI interrupts disabled.

NMI masking is a bit, so it'd be really wasteful not to have an
attribute to keep NMI enabled in the same place ...

  Potentially, an NMI could be latched (while in SMM or upon exit) and
  serviced upon exit [...]

This "Potentially" could be in the sense that the whole 3rd paragraph is
only applicable to some ancient SMM design :)

The 1st paragraph has quite clear sentence:

  If NMIs were blocked before the SMI occurred, they are blocked after
  execution of RSM.

so I'd just ignore the 3rd paragraph ...

And the APM 2:10.3.3 Exceptions and Interrupts
  NMI—If an NMI occurs while the processor is in SMM, it is latched by
  the processor, but the NMI handler is not invoked until the processor
  leaves SMM with the execution of an RSM instruction.  A pending NMI
  causes the handler to be invoked immediately after the RSM completes
  and before the first instruction in the interrupted program is
  executed.

  An SMM handler can unmask NMI interrupts by simply executing an IRET.
  Upon completion of the IRET instruction, the processor recognizes the
  pending NMI, and transfers control to the NMI handler. Once an NMI is
  recognized within SMM using this technique, subsequent NMIs are
  recognized until SMM is exited. Later SMIs cause NMIs to be masked,
  until the SMM handler unmasks them.

makes me think that we should unmask them unconditionally or that SMM
doesn't do anything with NMI masking.

If we can choose, less NMI nesting seems like a good idea.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/