[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250902192609.GL3245006@noisy.programming.kicks-ass.net>
Date: Tue, 2 Sep 2025 21:26:09 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Kees Cook <kees@...nel.org>, alyssa.milburn@...el.com,
scott.d.constable@...el.com, Joao Moreira <joao@...rdrivepizza.com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Nathan Chancellor <nathan@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>, ojeda@...nel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86,ibt: Use UDB instead of 0xEA
On Tue, Sep 02, 2025 at 09:04:51AM -0700, Alexei Starovoitov wrote:
> On Tue, Sep 2, 2025 at 1:19 AM Peter Zijlstra <peterz@...radead.org> wrote:
> >
> >
> > Because this is all somewhat magical code, and this change is a little
> > on the large side, it as been suggested I 'upgrade' the Changelog some.
> >
> > On Mon, Sep 01, 2025 at 09:13:07PM +0200, Peter Zijlstra wrote:
> > >
> > > A while ago [0] FineIBT started using the 0xEA instruction to raise #UD.
> > > All existing parts will generate #UD in 64bit mode on that instruction.
> > >
> > > However; Intel/AMD have not blessed using this instruction, it is on
> > > their 'reserved' opcode list for future use.
> > >
> > > Peter Anvin worked the committees and got use of 0xD6 blessed, it
> > > shall be called UDB (per the next SDM or so), and it being a single
> > > byte instruction is easy to slip into a single byte immediate -- as
> > > is done by this very patch.
> > >
> > > Reworking the FineIBT code to use UDB wasn't entirely trivial. Notably
> > > the FineIBT-BHI1 case ran out of bytes. In order to condense the
> > > encoding some it was required to move the hash register from R10D to
> > > EAX (thanks hpa!).
> > >
> > > Per the x86_64 ABI, RAX is used to pass the number of vector registers
> > > for vararg function calls -- something that should not happen in the
> > > kernel. More so, the kernel is built with -mskip-rax-setup, which
> > > should leave RAX completely unused, allowing its re-use.
> >
> > [ For BPF; while the bpf2bpf tail-call uses RAX in its calling
> > convention, that does not use CFI and is unaffected. Only the
> > 'regular' C->BPF transition is covered by CFI. ]
>
> I cannot comprehend the new scheme, but thanks for heads up.
Anywhere in particular you're getting stuck? That is, where should I
improve the comments / changelog?
Powered by blists - more mailing lists