Messages in this thread | | | Date | Tue, 10 Jan 2023 11:47:21 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC |
| |
* Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> Jason, > > Would you mind commenting on the below? > > On Mon, 9 Jan 2023, Ingo Molnar wrote: > > > > For x86 kernel stack offset randomization uses the RDTSC instruction, > > > which causes an invalid opcode exception with hardware that does not > > > implement this instruction: > > > > > @@ -85,7 +86,8 @@ static inline void arch_exit_to_user_mod > > > * Therefore, final stack offset entropy will be 5 (x86_64) or > > > * 6 (ia32) bits. > > > */ > > > - choose_random_kstack_offset(rdtsc() & 0xFF); > > > + if (cpu_feature_enabled(X86_FEATURE_TSC)) > > > + choose_random_kstack_offset(rdtsc() & 0xFF); > > > } > > > > While this is an obscure corner case, falling back to 0 offset silently > > feels a bit wrong - could we at least attempt to generate some > > unpredictability in this case? > > > > It's not genuine entropy, but we could pass in a value that varies from > > task to task and which is not an 'obviously known' constant value like the > > 0 fallback? > > > > For example the lowest 8 bits of the virtual page number of the current > > task plus the lowest 8 bits of jiffies should vary from task to task, has > > some time dependence and is cheap to compute: > > > > (((unsigned long)current >> 12) + jiffies) & 0xFF > > > > This combined with the per-CPU forward storage of previous offsets: > > > > #define choose_random_kstack_offset(rand) do { \ > > if (static_branch_maybe(CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT, \ > > &randomize_kstack_offset)) { \ > > u32 offset = raw_cpu_read(kstack_offset); \ > > offset ^= (rand); \ > > raw_cpu_write(kstack_offset, offset); \ > > } \ > > > > Should make this reasonably hard to guess for long-running tasks even if > > there's no TSC - and make it hard to guess even for tasks whose creation an > > attacker controls, unless there's an info-leak to rely on. > > Sure, I'm fine implementing it, even in such a way so as not to cause a > code size/performance regression for X86_TSC configurations. But is the > calculation really unpredictable enough? [...]
It's not binary: it's obviously not as good as a TSC, but my point is that 'something cheap & variable' is clearly better than 'zero offset all the time'.
Thanks,
Ingo
| |