On Tue, Oct 25, 2022, at 18:28, Maciej W. Rozycki wrote:
> On Sun, 23 Oct 2022, Linus Torvalds wrote:
>
>> In fact, I don't understand how current kernels work on an i486 at
>> all, since it looks like
>>
>> exit_to_user_mode_prepare ->
>> arch_exit_to_user_mode_prepare
>>
>> ends up having an unconditional 'rdtsc' instruction in it.
>> >
> The fix here is obviously and trivially:
>
> select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET if !M486SX && !M486
I think that would be "if X86_TSC", otherwise you still include the
TSC-less 586-class (5x86, 6x86, Elan, Winchip C6, MediaGX, ...)
> So what's the actual burden from keeping this support around? Would my
> proposal to emulate CMPXCHG8B (and possibly RDTSC) in #UD handler help?
That sounds worse to me than the current use of runtime alternatives
for picking between cmpxchg8b_emu and the native instruction.
For arm32, we have a combination of two other approaches:
- On the oldest processors that never had SMP support (ARMv5 and
earlier), it is not possible to enable support for SMP at all.
Using a Kconfig 'depends on X86_CMPXCHG64' for CONFIG_SMP would
still allow building 486 kernels, but completely avoid the problem
of trying to make the same kernel work on later SMP machines.
- For the special case of early ARMv6 hardware that has 32-bit
atomics but not 64-bit ones, the kernel just falls back to
CONFIG_GENERIC_ATOMIC64 and no cmpxchg64(). The same should work
for an i486+SMP kernel. It's obviously slower, but most users
can trivially avoid this by either running an i686 SMP kernel
or an i486 UP kernel.
Arnd
