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: <7a82aeec-7db5-4e06-abb4-9f041aaf2fb0@citrix.com>
Date: Tue, 6 Jan 2026 20:38:17 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: seanjc@...gle.com
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, chengkev@...gle.com,
 kvm@...r.kernel.org, linux-kernel@...r.kernel.org, pbonzini@...hat.com,
 yosry.ahmed@...ux.dev
Subject: Re: [PATCH 1/2] KVM: SVM: Generate #UD for certain instructions when
 SVME.EFER is disabled

> What about STGI?  Per the APM, it #UDs if:
>
>   Secure Virtual Machine was not enabled (EFER.SVME=0) and both of the following
>   conditions were true:
>     • SVM Lock is not available, as indicated by CPUID Fn8000_000A_EDX[SVML] = 0.
>     • DEV is not available, as indicated by CPUID Fn8000_0001_ECX[SKINIT] = 0.

15.31 states this more clearly.

"On processors that support the SVM-Lock feature, SKINIT and STGI can be
executed even if EFER.SVME=0."

SKINIT is AMD's version of Intel TXT.  The Secure Loader (15.27.1,
equivalent of the TXT ACM, left as an exercise to the programmer) is
started with GIF=0, and is expected to execute a single STGI instruction
when it's in a happy state to start taking interrupts.

SVM-Lock is a rough equivalent of Intel's
FEAT_CTRL.VMX_{IN,OUT}SIDE_SMX.  I still don't understand why the TCG
insisted on there being a way to lock out hypervisor support when using
DTRM, but if you don't implement SVM Lock and SKINIT, then AFAICT STGI
has the same fault behaviour as CLGI,

Be aware that SVM was added in the K8 RevF, and SKINIT was added in
Fam10h RevC, 3 generations later, so there were CPUs which had SVM and
no SVM-Lock.  It's not clear if there were CPUs with SVM-Lock but not
SKINIT, but given that it's enumerated separately, I expect there might be.

~Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ