linux-kernel - RE: [PATCH v2 12/25] KVM: VMX: Handle FRED event data

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: <SA1PR11MB6734740F9B6085E0997A4179A8E72@SA1PR11MB6734.namprd11.prod.outlook.com>
Date: Fri, 10 May 2024 09:36:03 +0000
From: "Li, Xin3" <xin3.li@...el.com>
To: "Gao, Chao" <chao.gao@...el.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "linux-doc@...r.kernel.org"
	<linux-doc@...r.kernel.org>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "corbet@....net"
	<corbet@....net>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "shuah@...nel.org"
	<shuah@...nel.org>, "vkuznets@...hat.com" <vkuznets@...hat.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "Shankar, Ravi V"
	<ravi.v.shankar@...el.com>, "xin@...or.com" <xin@...or.com>
Subject: RE: [PATCH v2 12/25] KVM: VMX: Handle FRED event data

> >+               if (kvm_is_fred_enabled(vcpu)) {
> >+                       u64 event_data = 0;
> >+
> >+                       if (is_debug(intr_info))
> >+                               /*
> >+                                * Compared to DR6, FRED #DB event data saved on
> >+                                * the stack frame have bits 4 ~ 11 and 16 ~ 31
> >+                                * inverted, i.e.,
> >+                                *   fred_db_event_data = dr6 ^ 0xFFFF0FF0UL
> >+                                */
> >+                               event_data = vcpu->arch.dr6 ^ DR6_RESERVED;
> >+                       else if (is_page_fault(intr_info))
> >+                               event_data = vcpu->arch.cr2;
> >+                       else if (is_nm_fault(intr_info))
> >+                               event_data =
> >+ to_vmx(vcpu)->fred_xfd_event_data;
> >+
> 
> IMO, deriving an event_data from CR2/DR6 is a little short-sighted because the
> event_data and CR2/DR6 __can__ be different, e.g., L1 VMM __can__ set CR2 to A
> and event_data field to B (!=A) when injecting #PF.

VMM should guarantee a FRED guest _sees_ consistent values in CR6/DR6
and event data. If not it's just a VMM bug that we need to fix.

> 
> And this approach cannot be extended to handle a (future) exception whose
> event_data isn't tied to a dedicated register like CR2/DR6.

See below.

> Adding a new field fred_xfd_event_data in struct vcpu has problems too:
> fred_xfd_event_data gets lost during migration;

I'm not bothered, because this is not hard to fix, right?

> strickly speaking, event_data is tied
> to an exception rather than a CPU. e.g., the CPU may detect a nested exception when
> delivering one and both have their own event_data.

No, don't get me wrong. An event data has to be _regenerated_ after
a nested exception is handled and the original instruction flow is
restarted. 
sometimes the original event could be gone.

We don't say an event data is tied to an exception or a CPU, which
is just confusing, or misleading.

> I think we can make event_data a property of exceptions. i.e., add a payload2 to
> struct kvm_queued_exception. and add new APIs to kvm_queue_exception* family to
> accept a payload2 and in VMX code, just program payload2 to the VMCS event_data
> field if FRED is enabled. KVM ABI should be extended as well to pass
> payload2 to userspace like how the payload is handled in
> kvm_vcpu_ioctl_x86_get/put_vcpu_events.

Yes, it's very likely that we will need to add a payload2 in future,
but NOT now. 2 reasons:

1) The first-generation FRED is designed to NOT go too far from what
   IDT can do. And FRED event data is conceptually an alias of CR2/DR6
   in the latest FRED spec (not considering xfd event data for now).
   And the existing payload is a nice match for now;

2) FRED is an extendable CPU architecture, which allows the structure
   of event data to become way bigger and complicated. Let's not assume
   anything and add a payload2 too early.