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]
Date:   Thu, 17 Aug 2023 07:45:39 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Binbin Wu <binbin.wu@...ux.intel.com>
Cc:     Zeng Guang <guang.zeng@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        H Peter Anvin <hpa@...or.com>, kvm@...r.kernel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/8] KVM: x86: Use a new flag for branch instructions

On Thu, Aug 17, 2023, Binbin Wu wrote:
> 
> 
> On 8/16/2023 10:38 PM, Sean Christopherson wrote:
> > On Wed, Aug 16, 2023, Binbin Wu wrote:
> > > 
> > > On 8/16/2023 6:51 AM, Sean Christopherson wrote:
> > > > Rather than call out individual use case, I would simply state that as of this
> > > > patch, X86EMUL_F_BRANCH and X86EMUL_F_FETCH are identical as far as KVM is
> > > > concernered.  That let's the reader know that (a) there's no intended change in
> > > > behavior and (b) that the intent is to effectively split all consumption of
> > > > X86EMUL_F_FETCH into (X86EMUL_F_FETCH | X86EMUL_F_BRANCH).
> > > How about this:
> > > 
> > >      KVM: x86: Use a new flag for branch targets
> > > 
> > >      Use the new flag X86EMUL_F_BRANCH instead of X86EMUL_F_FETCH in
> > > assign_eip()
> > >      to distinguish instruction fetch and branch target computation for
> > > feature(s)
> > Just "features", i.e. no parentheses...
> > 
> > >      that handle differently on them.
> > ...and tack on ", e.g. LASS and LAM." at the end.
> OK, but only LASS here, since LAM only applies to addresses for data
> accesses, i.e, no need to distingush the two flag.

Oh, right.   Thanks!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ