linux-kernel - Re: [PATCH v2 0/2] x86/cpu: fix invalid MTRR mask values for SEV or TME

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: <CABgObfbUcG5NyKhLOnihWKNVM0OZ7zb9R=ADzq7mjbyOCg3tUw@mail.gmail.com>
Date: Tue, 13 Feb 2024 16:45:06 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	Zixi Chen <zixchen@...hat.com>, Adam Dunlap <acdunlap@...gle.com>, 
	"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, Xiaoyao Li <xiaoyao.li@...el.com>, 
	Kai Huang <kai.huang@...el.com>, Dave Hansen <dave.hansen@...ux.intel.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>, x86@...nel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH v2 0/2] x86/cpu: fix invalid MTRR mask values for SEV or TME

On Sun, Feb 4, 2024 at 6:21 PM Paolo Bonzini <pbonzini@...hat.com> wrote:
> On Fri, Feb 2, 2024 at 12:08 AM Paolo Bonzini <pbonzini@...hat.com> wrote:
> > On Thu, Feb 1, 2024 at 7:29 PM Dave Hansen <dave.hansen@...el.com> wrote:
> > > I really wanted get_cpu_address_sizes() to be the one and only spot
> > > where c->x86_phys_bits is established.  That way, we don't get a bunch
> > > of code all of the place tweaking it and fighting for who "wins".
> > > We're not there yet, but the approach in this patch moves it back in the
> > > wrong direction because it permits the random tweaking of c->x86_phys_bits.
> >
> > There is unfortunately an important hurdle [...] in that
> > currently the BSP and AP flows are completely different. For the BSP
> > the flow is ->c_early_init(), then get_cpu_address_sizes(), then again
> > ->c_early_init() called by ->c_init(), then ->c_init(). For APs it is
> > get_cpu_address_sizes(), then ->c_early_init() called by ->c_init(),
> > then the rest of ->c_init(). And let's not even look at
> > ->c_identify(). [...] get_cpu_address_sizes()
> > is called too early to see enc_phys_bits on APs. But it was also
> > something that fbf6449f84bf didn't take into account, because it left
> > behind the tentative initialization of x86_*_bits in identify_cpu(),
> > while removing it from early_identify_cpu().  And

Ping, either for applying the original patches or for guidance on how
to proceed.

Paolo