linux-kernel - Re: [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry

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:   Sun, 7 Aug 2022 12:02:41 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Dave Hansen <dave.hansen@...el.com>, ira.weiny@...el.com,
        Rik van Riel <riel@...riel.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org, kernel-team@...com
Subject: Re: [RFC PATCH 5/5] x86/entry: Store CPU info on exception entry

* Borislav Petkov <bp@...en8.de> wrote:

> On Sat, Aug 06, 2022 at 11:01:06AM +0200, Ingo Molnar wrote:
> > It's still 2 instructions more than what we had before, while the 
> > fault-time CPU number is only needed infrequently AFAICS.
> 
> With the amount of logical cores ever increasing and how CPU packages
> (nodes, L3 sharing, you name it) get more and more complex topology,
> I'd say the 2 insns to show the CPU number in every exception is a good
> thing to do.

We can show it - I'm arguing against extracting it too early, which costs 
us 2 instructions in the exception fast path - while in 99.999999999% of 
the cases we don't use that field at all ...

> Arguably, we probably should've even done it already...

Yeah, so I'm not against Rik's patch that prints the CPU number - that's 
indeed useful and I'd like to see it merged.

I'm arguing against extracting the CPU so early as to impact the exception 
fast path.

Thanks,

	Ingo