On Wed, 16 Oct 2024 at 04:10, Nathan Chancellor wrote:
>
> On Tue, Oct 15, 2024 at 12:56:57PM +0200, Ard Biesheuvel wrote:
> > On Mon, 14 Oct 2024 at 22:59, Kees Cook wrote:
> > >
> > > On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
> > > > However, if a non-TLS definition of the
On Tue, Oct 15, 2024 at 12:56:57PM +0200, Ard Biesheuvel wrote:
> On Mon, 14 Oct 2024 at 22:59, Kees Cook wrote:
> >
> > On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
> > > However, if a non-TLS definition of the symbol in question is visible in
> > > the same compilation unit (w
On Mon, 14 Oct 2024 at 22:59, Kees Cook wrote:
>
> On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
> > However, if a non-TLS definition of the symbol in question is visible in
> > the same compilation unit (which amounts to the whole of vmlinux if LTO
> > is enabled), it will drop
On Wed, Oct 09, 2024 at 02:43:53PM +0200, Ard Biesheuvel wrote:
> However, if a non-TLS definition of the symbol in question is visible in
> the same compilation unit (which amounts to the whole of vmlinux if LTO
> is enabled), it will drop the per-CPU prefix and emit a load from a
> bogus address.
From: Ard Biesheuvel
GCC and Clang both implement stack protector support based on Thread
Local Storage (TLS) variables, and this is used in the kernel to
implement per-task stack cookies, by copying a task's stack cookie into
a per-CPU variable every time it is scheduled in.
Both now also imple
