[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202111021023.0E5188EC60@keescook>
Date: Tue, 2 Nov 2021 10:26:29 -0700
From: Kees Cook <keescook@...omium.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ard Biesheuvel <ardb@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Sami Tolvanen <samitolvanen@...gle.com>,
X86 ML <x86@...nel.org>, Josh Poimboeuf <jpoimboe@...hat.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Sedat Dilek <sedat.dilek@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-hardening@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
llvm@...ts.linux.dev
Subject: Re: [PATCH v5 00/15] x86: Add support for Clang CFI
On Thu, Oct 28, 2021 at 10:29:05PM +0200, Peter Zijlstra wrote:
> Now, since code (on x86) is variable length, there are no spare bits in
> the code address, but since static_call_key is aligned, we have spare
> bits. It is those bits we use to encode TAIL (Bit0) and INIT (Bit1).
>
> If INIT, the address points to an __init section and we shouldn't try
> and touch if after those have been freed or bad stuff happens.
>
> If TAIL, it's a tail-call and we get to write a jump instruction instead
> of a call instruction.
I think this is the part that I was missing: the information is about
the _address_, but it's stored in the _key_'s low bits (regardless of
the key's actual/masked key pointer).
> [...]
> Hope that clarifies things, instead of making it worse :-)
It does help, yes, thanks! I will need to read it again and go follow
along in the code, but yes, that helps explain it.
--
Kees Cook
Powered by blists - more mailing lists