From: Kees Cook <kees@kernel.org>
To: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Cc: Qing Zhao <qing.zhao@oracle.com>, Uros Bizjak <ubizjak@gmail.com>,
Joseph Myers <josmyers@redhat.com>,
Richard Biener <rguenther@suse.de>,
Jeff Law <jeffreyalaw@gmail.com>,
Andrew Pinski <pinskia@gmail.com>,
Jakub Jelinek <jakub@redhat.com>,
Martin Uecker <uecker@tugraz.at>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ardb@kernel.org>, Jan Hubicka <hubicka@ucw.cz>,
Richard Earnshaw <richard.earnshaw@arm.com>,
Richard Sandiford <richard.sandiford@arm.com>,
Marcus Shawcroft <marcus.shawcroft@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>,
Kito Cheng <kito.cheng@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Waterman <andrew@sifive.com>,
Jim Wilson <jim.wilson.gcc@gmail.com>,
Dan Li <ashimida.1990@gmail.com>,
Sami Tolvanen <samitolvanen@google.com>,
Ramon de C Valle <rcvalle@google.com>,
Joao Moreira <joao@overdrivepizza.com>,
Nathan Chancellor <nathan@kernel.org>,
Bill Wendling <morbo@google.com>,
"Osterlund, Sebastian" <sebastian.osterlund@intel.com>,
"Constable, Scott D" <scott.d.constable@intel.com>,
gcc-patches@gcc.gnu.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v9 5/7] aarch64: Add AArch64 Kernel Control Flow Integrity implementation
Date: Fri, 12 Dec 2025 17:40:50 -0800 [thread overview]
Message-ID: <202512121725.9CC129F0@keescook> (raw)
In-Reply-To: <CALvbMcCFQbBO2McnTfWVHEcVvZfy+U6FSM7jMPyG-1-N9RP14A@mail.gmail.com>
On Fri, Dec 12, 2025 at 02:47:57PM -0800, Andrew Pinski wrote:
> On Tue, Dec 9, 2025 at 6:23 PM Kees Cook <kees@kernel.org> wrote:
> > Implement AArch64-specific KCFI backend.
> [...]
>
> From an aarch64 point of view this is ok (except for a few minor
> things [see below in the patch itself] which can be bundled up with
> the fixes for the review of the middle-end parts and don't need an
> extra approval).
Thanks! I will go through these and fix them up for v10.
> The only open question with the aarch64 side of things (and other
> targets) is how to represent the kfci calls, should there be wrapping
> or not.
> Right now I am ok with the wrapping but I am not a fan of it because
> it introduces complexity to the call patterns. It is definitely
> something that should be looked into but I am not going to block this
> set of patches for it.
> And using define_subst/define_subst_attr if we decide to stay with the
> wrapping with the kfci rtl, is something to look into but that can
> wait too.
Yeah, I would love more guidance on this; Uros suggested using
define_subst during the x86 review, and I was able to use it there
because x86's expansion and call patterns don't use PARALLEL. When I
tried to apply define_subst to the other architectures with PARALLEL it
got extremely complex, and ended up being more complicated than what I
already had. See this for my (brief) comments on this attempt in v7:
https://lore.kernel.org/linux-hardening/20251117201219.makes.617-kees@kernel.org/
Maybe I just didn't see the right way to do it, so I'm happy to try
something different here if there's a better method.
> [...]
> > +const char *
> > +aarch64_output_kcfi_insn (rtx_insn *insn, rtx *operands)
> > +{
> > + /* Target register is operands[0]. */
> > + rtx target_reg = operands[0];
> > + gcc_assert (REG_P (target_reg));
> > +
> > + /* Get KCFI type ID from operand[3]. */
> > + uint32_t type_id = (uint32_t) INTVAL (operands[3]);
>
> Use UINTVAL .
Now fixed (for all archs).
> > +
> > + /* Calculate typeid offset from call target. */
> > + HOST_WIDE_INT offset = -kcfi_get_typeid_offset ();
> > +
> > + /* Get unique label number for this KCFI check. */
> > + int labelno = kcfi_next_labelno ();
> > +
> > + /* Generate custom label names. */
> > + char trap_name[32];
> > + char call_name[32];
> > + ASM_GENERATE_INTERNAL_LABEL (trap_name, "Lkcfi_trap", labelno);
> > + ASM_GENERATE_INTERNAL_LABEL (call_name, "Lkcfi_call", labelno);
> > +
> > + /* Load actual type into w16 from memory at offset using ldur. */
> > + rtx temp_operands[2];
> > + temp_operands[0] = target_reg;
> > + temp_operands[1] = GEN_INT (offset);
> > + output_asm_insn ("ldur\tw16, [%0, #%1]", temp_operands);
> > +
> > + /* Load expected type into w17 using mov/movk sequence. */
> > + fprintf (asm_out_file, "\tmov\tw17, #%u\n", type_id & 0xFFFF);
> > + fprintf (asm_out_file, "\tmovk\tw17, #%u, lsl #16\n", (type_id >> 16) & 0xFFFF);
> > +
> > + /* Compare types. */
> > + fprintf (asm_out_file, "\tcmp\tw16, w17\n");
> > +
> > + /* Output conditional branch to call label. */
> > + fputs ("\tb.eq\t", asm_out_file);
> > + assemble_name (asm_out_file, call_name);
> > + fputc ('\n', asm_out_file);
> > +
> > + /* Output trap label and BRK instruction. */
> > + ASM_OUTPUT_LABEL (asm_out_file, trap_name);
> > +
> > + /* Calculate and emit BRK with ESR encoding. */
> > + unsigned type_index = R17_REGNUM;
> > + unsigned addr_index = REGNO (target_reg) - R0_REGNUM;
> > + unsigned esr_value = 0x8000 | ((type_index & 31) << 5) | (addr_index & 31);
> > +
> > + fprintf (asm_out_file, "\tbrk\t#%u\n", esr_value);
>
> It might be useful to print the hex instead of the decimal here.
> Either way is ok.
Yeah, that's more human-readable. Now changed.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2025-12-13 1:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 2:20 [PATCH v9 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Kees Cook
2025-12-10 2:20 ` [PATCH v9 1/7] typeinfo: Introduce KCFI typeinfo mangling API Kees Cook
2025-12-12 23:07 ` Andrew Pinski
2025-12-13 1:24 ` Kees Cook
2025-12-13 1:29 ` Andrew Pinski
2025-12-13 1:43 ` Kees Cook
2025-12-10 2:20 ` [PATCH v9 2/7] kcfi: Add core Kernel Control Flow Integrity infrastructure Kees Cook
2025-12-10 4:00 ` Andrew Pinski
2025-12-13 2:30 ` Kees Cook
2025-12-10 2:20 ` [PATCH v9 3/7] kcfi: Add regression test suite Kees Cook
2025-12-10 2:20 ` [PATCH v9 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation Kees Cook
2025-12-10 2:20 ` [PATCH v9 5/7] aarch64: Add AArch64 " Kees Cook
2025-12-10 3:48 ` Andrew Pinski
2025-12-12 22:47 ` Andrew Pinski
2025-12-13 1:40 ` Kees Cook [this message]
2025-12-10 2:20 ` [PATCH v9 6/7] arm: Add ARM 32-bit " Kees Cook
2025-12-10 2:20 ` [PATCH v9 7/7] riscv: Add RISC-V " Kees Cook
2025-12-10 18:55 ` [PATCH v9 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Sam James
2025-12-11 0:07 ` Kees Cook
2026-01-01 22:42 ` Andrew Pinski
2026-01-02 3:42 ` Kees Cook
2026-01-09 5:48 ` Andrew Pinski
2026-01-09 18:22 ` Kees Cook
2026-01-09 18:43 ` Jeffrey Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202512121725.9CC129F0@keescook \
--to=kees@kernel.org \
--cc=andrew.pinski@oss.qualcomm.com \
--cc=andrew@sifive.com \
--cc=ardb@kernel.org \
--cc=ashimida.1990@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=jim.wilson.gcc@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=josmyers@redhat.com \
--cc=kito.cheng@gmail.com \
--cc=kyrylo.tkachov@arm.com \
--cc=linux-hardening@vger.kernel.org \
--cc=marcus.shawcroft@arm.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pinskia@gmail.com \
--cc=qing.zhao@oracle.com \
--cc=rcvalle@google.com \
--cc=rguenther@suse.de \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
--cc=samitolvanen@google.com \
--cc=scott.d.constable@intel.com \
--cc=sebastian.osterlund@intel.com \
--cc=ubizjak@gmail.com \
--cc=uecker@tugraz.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.