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] [day] [month] [year] [list]
Message-ID: <ZPD3C/AFnvs9S6vs@google.com>
Date:   Thu, 31 Aug 2023 13:24:43 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Zeng Guang <guang.zeng@...el.com>
Cc:     Binbin Wu <binbin.wu@...ux.intel.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        Chao Gao <chao.gao@...el.com>, Kai Huang <kai.huang@...el.com>,
        "David.Laight@...lab.com" <David.Laight@...lab.com>,
        "robert.hu@...ux.intel.com" <robert.hu@...ux.intel.com>
Subject: Re: [PATCH v10 0/9] Linear Address Masking (LAM) KVM Enabling

On Fri, Aug 25, 2023, Zeng Guang wrote:
> 
> On 8/18/2023 9:53 PM, Sean Christopherson wrote:
> > On Fri, Aug 18, 2023, Binbin Wu wrote:
> > > On 8/17/2023 5:17 PM, Binbin Wu wrote:
> > > > On 8/17/2023 6:25 AM, Sean Christopherson wrote:
> > > > > On Wed, Jul 19, 2023, Binbin Wu wrote:
> > > > > For the next version, can you (or Zeng) send a single series for LAM
> > > > > and LASS?  They're both pretty much ready to go, i.e. I don't expect
> > > > > one to hold up the other at this point, and posting a single series
> > > > > will reduce the probability of me screwing up a conflict resolution
> > > > > or missing a dependency when applying.
> > > > > 
> > > Hi Sean,
> > > Do you still prefer a single series for LAM and LASSĀ  for the next version
> > > when we don't need to rush for v6.6?
> > Yes, if it's not too much trouble on your end.  Since the two have overlapping
> > prep work and concepts, and both series are in good shape, my strong preference
> > is to grab them at the same time.  I would much rather apply what you've tested
> > and reduce the probability of messing up any conflicts.
> > 
> > 
> > 
> Hi Sean,
> One more concern, KVM LASS patch has an extra dependency on kernel LASS
> series in which enumerates lass feature bit (X86_FEATURE_LASS/X86_CR4_LASS).
> So far kernel lass patch is still under review, as alternative we may extract
> relevant patch part along with kvm lass patch set for a single series in case
> kernel lass cannot be merged before v6.7.  Do you think it OK in that way?

Hmm, since getting LASS support in KVM isn't urgent, I think it makes sense to
wait for kernel support, no reason to complicate things.

To avoid delaying LAM, just put all the LAM patches first, it's trivally easy for
me to grab a partial series.

Speaking of kernel support, one thing we should explicit discuss is whether or
not KVM should require kernel support for LASS, i.e. if KVM should support LASS
if it's present in hardware, even if it's not enabled in the host.

Looking at the kernel patches, LASS will be disabled if vsyscall is in emulate
mode.  Ah, digging deeper, that's an incredibly esoteric and deprecated mode.
bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE").

So scratch that, let's again keep things simple.  Might be worth a call out in
the changelog that adds F(LASS), though.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ