[PATCH v4 0/5] ARM: support THREAD_INFO_IN_TASK

[Ard Biesheuvel]

On Tue, 14 Sept 2021 at 11:44, Arnd Bergmann <arnd at arndb.de> wrote:
>
> On Mon, Sep 13, 2021 at 12:39 PM Ard Biesheuvel <ardb at kernel.org> wrote:
> >
> > Placing thread_info in the kernel stack leaves it vulnerable to stack
> > overflow attacks. This short series addresses that by using the existing
> > THREAD_INFO_IN_TASK infrastructure.
> >
> > This v4 is a follow-up to Keith's v3 [0], which did not address all
> > concerns I raised in response to v2. After collaborating with Keith
> > off-list, we decided that I should go ahead and post our joint v4.
> >
> > Changes since v3:
> >
> > - Leave the CPU field in thread_info, and keep it in sync at context
> >   switch time. This is by far the easiest and cleanest way to work
> >   around the fact that it is infeasible to implement
> >   raw_smp_processor_id() in terms of task_struct::cpu (for reasons of
> >   header soup).
> >
> > - Drop the VFP changes, they are no longer necessary given the previous
> >   point.
> >
> > - Drop the change to pass the CPU number to secondary_start_kernel().
> >   Given that we also need to pass the idle task pointer, which carries
> >   the CPU number, passing the CPU number directly is redundant.
> >
> > - Use the TPIDRURO register to carry 'current' while running in the
> >   kernel, and keep using TPIDRPRW for the per-CPU offset as before. This
> >   way, there is no need to make any changes to the way the per-CPU offsets
> >   are programmed. It also avoids the concurrency issues that would
> >   result from carrying the 'current' pointer in a per-CPU variable.
> >
> > - Update the per-task stack protector plugin to pull the stack canary
> >   value directly from the task struct.
>
> I haven't looked in detail, but it all looks great to me so far.
>
> On a related note, this reminds me of the CONFIG_IRQSTACK series
> that was posted last year[1] and probably attempted before that.
> I'd have to get back to understanding all the details of that discussion,
> but I have some hope that adding irqstacks would become much
> easier after your series. Any thoughts on that?
>

Yes, not having to rely on the stack pointer for thread_info/current
seems to make this a lot easier. And eith mentioned that he is also
interested in vmap'ed stacks for ARM, so I have a suspicion that we
will end up picking up some IRQ stack changes in the process as well.