linux-kernel - Re: [PATCH v5 04/15] x86/mtrr: support setting MTRR state for software defined MTRRs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 3 Apr 2023 09:44:46 +0000
From:   "Huang, Kai" <kai.huang@...el.com>
To:     "Gross, Jurgen" <jgross@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "hpa@...or.com" <hpa@...or.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "mikelley@...rosoft.com" <mikelley@...rosoft.com>
Subject: Re: [PATCH v5 04/15] x86/mtrr: support setting MTRR state for
 software defined MTRRs

On Mon, 2023-04-03 at 11:35 +0200, Juergen Gross wrote:
> On 03.04.23 11:27, Huang, Kai wrote:
> > 
> > > > >    /**
> > > > >     * mtrr_type_lookup - look up memory type in MTRR
> > > > >     *
> > > > > diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
> > > > > index 1beb38f7a7a3..1c19d67ddab3 100644
> > > > > --- a/arch/x86/kernel/cpu/mtrr/mtrr.c
> > > > > +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
> > > > > @@ -666,6 +666,15 @@ void __init mtrr_bp_init(void)
> > > > >    	const char *why = "(not available)";
> > > > >    	unsigned int phys_addr;
> > > > >    
> > > > > +	if (!generic_mtrrs && mtrr_state.enabled) {
> > > > > +		/* Software overwrite of MTRR state, only for generic case. */
> > > > 							      ^
> > > > 							      !generic case?
> > > 
> > > No. This test just verifies that the (visible) MTRR feature is switched off,
> > > as there are no ways to modify any MTRR registers in the overwrite case.
> > > 
> > > I can make this more obvious in a comment.
> > 
> > Should the comment say something like (because it applies to the code inside the
> > check):
> > 
> > 
> > 	If we have a static (synthetic) MTRR already established for special
> > 	VMs, we still need to calculate the physical address bits using
> > generic
> > 	way, because the hardware to run those special VMs indeed has MTRR.
> > 
> > That explains why 'true' is passed to mtrr_calc_physbits().
> 
> I'd rather say that the interface of mtrr_overwrite_state() is based on the
> interface of generic MTRRs.

Sure fine to me too.  Thanks.