On Wed, 8 Sept 2021 at 09:01, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxxxxx> wrote: > > On 08/09/2021 00:00, Keith Packard 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 is the third version of this series, in this version the changes > > are restricted to hardware which provides the TPIDRPRW register. This > > register is repurposed from holding the per_cpu_offset value to > > holding the 'current' value as that allows fetching this value > > atomically so that it can be used in a preemptable context. > > > > The series is broken into seven pieces: > > > > 1) Change the secondary_start_kernel API to receive the cpu > > number. This avoids needing to be able to find this value independently in > > future patches. > > > > 2) Change the secondary_start_kernel API to also receive the 'task' > > value. Passing the value to this function also avoids needing to > > be able to discover it independently. > > > > 3) A cleanup which avoids assuming that THREAD_INFO_IN_TASK is not set. > > > > 4) A hack, borrowed from the powerpc arch, which allows locating the 'cpu' > > field in either thread_info or task_struct, without requiring linux/sched.h > > to be included in asm/smp.h > > > > 5) Disable the optimization storing per_cpu_offset in TPIDRPRW. This leaves > > the register free to hold 'current' instead. > > > > 6) Use TPIDRPRW for 'current'. This is enabled for either CPU_V6K or CPU_V7, > > but not if CPU_V6 is also enabled. > > > > 7) Enable THREAD_INFO_IN_TASK whenever TPIDRPRW is used to hold 'current'. > > Hi, > > Thanks for your patches. This seems to be a v3 but the patches are not > marked with it. Use "-v3" in format-patch to get it right. > > The email here also lacks diffstat which is useful, for example to check > whether any maintainer's relevant files are touched here. You can get it > with "--cover-letter". > > In total the command should look like: > git format-patch --cover-letter -v3 -7 HEAD > > Of course you can use any other tools to achieve the same result but as > of now - result is not the same. > Also, this ended up in my GMail spam folder, likely due to some antispam ID header being set incorrectly?
