linux-kernel - Re: [RFC][PATCH] x86,ibt: Use UDB instead of 0xEA

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] [day] [month] [year] [list]

Message-ID: <880F0E7C-86AE-4007-863F-E58B4C3C131C@zytor.com>
Date: Fri, 15 Aug 2025 10:28:43 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
        Peter Zijlstra <peterz@...radead.org>
CC: x86@...nel.org, kees@...nel.org, alyssa.milburn@...el.com,
        scott.d.constable@...el.com, joao@...rdrivepizza.com,
        samitolvanen@...gle.com, nathan@...nel.org,
        alexei.starovoitov@...il.com, mhiramat@...nel.org, ojeda@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH] x86,ibt: Use UDB instead of 0xEA

On August 15, 2025 10:21:48 AM PDT, Andrew Cooper <andrew.cooper3@...rix.com> wrote:
>On 15/08/2025 6:14 pm, H. Peter Anvin wrote:
>> On 2025-08-15 04:19, Andrew Cooper wrote:
>>>> CS Jcc, decodes to Jcc,pn for non-taken
>>>> DS Jcc, decodes to Jcc,pt for taken
>>> Ah, thanks.  I was looking at the hex in one of the comments and still
>>> couldn't figure it out.
>>>
>>> So with this notation, we also have the dual meaning of ,pt between the
>>> P4 and LNC.  At least the encoding is the same.
>>>
>> What "dual meaning?"
>
>Well, it has different semantics now it's been reintroduced in LNC. 
>(Only has any effect on a prediction miss, and causes a proactive decode
>resteer).
>
>Sure, it's "just perf" so can be argued as "compatible behaviour", but
>people caring about the ,pt / ,pn properties do need to know the different.
>
>~Andrew

The architectural semantics are "hint to the microarchitecture that this branch is strongly biased in one specific direction", and that has been true since the P4.

There are no other semantic guarantees, including, of course, that the hardware will do anything at all with it.

Performance tuning at the uarch level changes over time and will continue to do so, so if you don't distinguish between architectural behavior and performance you have to define pretty much every instruction as semantically different in each generation.