linux-kernel - Re: [PATCH v3 14/17] x86/mce/amd: Enable interrupt vectors once per-CPU on SMCA systems

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: <20250512153401.GA2355@yaz-khff2.amd.com>
Date: Mon, 12 May 2025 11:34:01 -0400
From: Yazen Ghannam <yazen.ghannam@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, Tony Luck <tony.luck@...el.com>,
	linux-kernel@...r.kernel.org, linux-edac@...r.kernel.org,
	Smita.KoralahalliChannabasappa@....com,
	Qiuxu Zhuo <qiuxu.zhuo@...el.com>
Subject: Re: [PATCH v3 14/17] x86/mce/amd: Enable interrupt vectors once
 per-CPU on SMCA systems

On Fri, May 09, 2025 at 04:08:21PM +0200, Borislav Petkov wrote:
> On Thu, May 08, 2025 at 11:53:00AM -0400, Yazen Ghannam wrote:
> > Let me flip it around. Why is this check needed at all?
> 
> As I said above, some BIOS f*ckup.
> 
> > Was there ever a real issue to resolve?
> 
> Not that I remember...
> 
> > It seems to me the deferred error updates are just following what other code
> > did.
> 
> Let's search the web for it:
> 
> * https://bbs.archlinux.org/viewtopic.php?id=299379
> 
> - silly guests, who cares
> 
> * https://gitlab.com/qemu-project/qemu/-/issues/2571
> 
> - another misguided qemu...
> 
> Aha:
> 
> https://lore.kernel.org/lkml/20241219124426.325747-1-pbonzini@redhat.com
> 
> the usual virt silly stuff.
> 
> > I figure the reason to have the platform give the offset to the OS is so
> > the OS doesn't hard code it (in case it needs to change). These offsets
> > were hard coded in the past (conflict between IBS/THR), and it caused
> > problems when the offsets switched in the hardware. The registers that
> > give the offsets were introduced soon after, I think.
> 
> Right.
> 
> > So the checks we do are defeating the purpose. The OS is still hard
> > coding the offsets. The goal of this change is to follow the intent of
> > the design. Sometimes we need to let go and trust [the BIOS]. ;)
> 
> Look at you being silly :-P
> 
> > Now we could update the checks to verify that an offset is not used for
> > multiple interrupt sources.
> 
> ... or, we won't do anything until someone in BIOS f*cks up again.
>  
> > Let's follow up with the design folks to be sure.
> 
> Yah, sounds like we will have to verify them after all. You can see how
> universally widespread the trust in BIOS is...
> 
> :-P
> 
> In any case, whatever you do, when you axe off stuff, write in the commit
> message why you do so. Silently removing it is making me want to know why it
> is ok now.
> 

Right, it sounds like we should take the values from the platform and
just make sure they aren't used for multiple sources. In other words, we
don't hard code the offsets, and we verify that each source has a unique
offset.

I agree we can leave this for now. So I'll drop this part from the patch.

I think this topic can be a separate set, and it should cover all APIC
LVT sources including IBS. I'll add it to the to-do list. :)

Thanks,
Yazen