On Wed, 19 Jan 2022 at 18:02, Ard Biesheuvel <a...@kernel.org> wrote: > > On Wed, 19 Jan 2022 at 17:54, Kyrylo Tkachov <kyrylo.tkac...@arm.com> wrote: > > > > Hi Ard, > > > > > -----Original Message----- > > > From: Gcc-patches <gcc-patches- > > > bounces+kyrylo.tkachov=arm....@gcc.gnu.org> On Behalf Of Ard > > > Biesheuvel via Gcc-patches > > > Sent: Monday, November 15, 2021 6:04 PM > > > To: linux-harden...@vger.kernel.org > > > Cc: Richard Sandiford <richard.sandif...@arm.com>; > > > thomas.preudho...@celest.fr; Keith Packard <keith...@amazon.com>; > > > gcc-patches@gcc.gnu.org; Kyrylo Tkachov <kyryo.tkac...@arm.com>; Ard > > > Biesheuvel <a...@kernel.org> > > > Subject: [PATCH v5 1/1] [ARM] Add support for TLS register based stack > > > protector canary access > > > > > > Add support for accessing the stack canary value via the TLS register, > > > so that multiple threads running in the same address space can use > > > distinct canary values. This is intended for the Linux kernel running in > > > SMP mode, where processes entering the kernel are essentially threads > > > running the same program concurrently: using a global variable for the > > > canary in that context is problematic because it can never be rotated, > > > and so the OS is forced to use the same value as long as it remains up. > > > > > > Using the TLS register to index the stack canary helps with this, as it > > > allows each CPU to context switch the TLS register along with the rest > > > of the process, permitting each process to use its own value for the > > > stack canary. > > > > I've tested this patch on an arm-none-linux-gnueabihf target and the > > results look clean. > > Have you tested this patch with a kernel build as well? (since the > > functionality is intended for that use). > > Of course. > > > If so, the patch is okay but please rebase it and repost so that we can > > commit it taking into account.... > > > > Will do.
I have sent out my v6 - please let me know if there is anything else I need to do to get this landed. Thanks, Ard.