Messages in this thread | | | From | David Laight <> | Subject | RE: [PATCH v2] x86: Disable kernel stack offset randomization for !TSC | Date | Tue, 10 Jan 2023 13:56:22 +0000 |
| |
From: Ingo Molnar > Sent: 10 January 2023 10:47 > > > * 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'.
Does it really matter if running on anything as old as a real 486? In reality they'll only be used for testing. There are more modern 486-class cpu for embedded use, but they almost certainly have a TSC.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |