linux-kernel - Re: [RFC PATCH 2/2] KVM: x86: Enable guest SSP read/write interface with new uAPIs

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: <ZmixMxni_YOysAuz@google.com>
Date: Tue, 11 Jun 2024 13:18:59 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Weijiang Yang <weijiang.yang@...el.com>
Cc: pbonzini@...hat.com, mlevitsk@...hat.com, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] KVM: x86: Enable guest SSP read/write interface
 with new uAPIs

On Tue, Jun 11, 2024, Weijiang Yang wrote:
> On 6/11/2024 9:17 AM, Sean Christopherson wrote:
> > On Thu, May 09, 2024, Yang Weijiang wrote:
> > Aha!  And then to prepare for a future where we add synthetic registers that
> > aren't routed through the MSR framework (which seems unlikely, but its trivially
> > easy to handle, so why not):
> > 
> > static int kvm_translate_synthetic_reg(struct kvm_x86_reg_id *reg)
> > {
> > 	switch (reg->index) {
> > 	case MSR_KVM_GUEST_SSP:
> > 		reg->type = KVM_X86_REG_MSR;
> > 		reg->index = MSR_KVM_INTERNAL_GUEST_SSP;
> > 		break;
> > 	default:
> > 		return -EINVAL;
> > 	}
> > 	return 0;
> > }
> > 
> > and then the caller would have slightly different ordering:
> > 
> >          if (id->type == KVM_X86_REG_SYNTHETIC_MSR) {
> >                  r = kvm_translate_synthetic_msr(&id->index);
> >                  if (r)
> >                          break;
> >          }
> > 
> >          r = -EINVAL;
> >          if (id->type != KVM_X86_REG_MSR)
> >                  break;
> I assume reg->type translation for GUEST_SSP is due to the fact it relies on
> CET common checking stuffs underneath for the register, i.e., it goes through
> existing MSR framework. But for future other synthetic MSRs, it needs to

Nit, other synthetic *registers*.

> refactor the code here so that it could be routed into new handling.  e.g.:
> 
> if (id->type == KVM_X86_REG_MSR)
>         go through MSR framework;
> else
>         go through other new handling;
> 
> But currently the new uAPIs are only for GUEST_SSP, so above suggested
> id->type check works.  Does it make sense?

Yep, we're on the same page.