Re: [kernel-hardening] [PATCH v4 26/29] sched: Allow putting thread_info into task_struct
From: Andy Lutomirski <luto@amacapital.net>
Date: 2016-07-11 14:55:41
Also in:
lkml
On Jul 11, 2016 3:08 AM, "Mark Rutland" [off-list ref] wrote:
Hi, On Sun, Jun 26, 2016 at 02:55:48PM -0700, Andy Lutomirski wrote:quoted
If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT, then thread_info is defined as a single 'u32 flags' and is the first entry of task_struct. thread_info::task is removed (it serves no purpose if thread_info is embedded in task_struct), and thread_info::cpu gets its own slot in task_struct. This is heavily based on a patch written by Linus.I've been considering how we'd implement this for arm64, and I suspect that we'll also need to fold our preempt_count into task_struct (following from the style of asm-generic/preempt.h). As far as I can see, we can't make our preempt-count a percpu variable as with x86, as our percpu ops themselves are based on disabling preemption.
How do you intend to find 'current' to get to the preempt count without first disabling preemption?
To that end, would it be possible to keep the thread_info definition per arch, even with CONFIG_THREAD_INFO_IN_TASK?
In principal, yes, but could you alternatively put it in thread_struct? My goal here is to encourage people to clean up their use of thread_info vs thread_struct at the same time. For x86, that cleanup was trivial -- most of the work was addressing relative to current instead of the stack pointer, and that had to happen regardless. --Andy