linux-kernel - Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <d24a5273-1c66-4653-9730-4de31ffcf0e8@app.fastmail.com>
Date:   Wed, 26 Oct 2022 17:43:59 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:     "Matthew Wilcox" <willy@...radead.org>,
        "Peter Zijlstra" <peterz@...radead.org>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        "Yu Zhao" <yuzhao@...gle.com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Andi Kleen" <ak@...ux.intel.com>,
        "Aneesh Kumar" <aneesh.kumar@...ux.ibm.com>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        "Hillf Danton" <hdanton@...a.com>, "Jens Axboe" <axboe@...nel.dk>,
        "Johannes Weiner" <hannes@...xchg.org>,
        "Jonathan Corbet" <corbet@....net>, "Mel Gorman" <mgorman@...e.de>,
        "Michael Larabel" <Michael@...haellarabel.com>,
        "Michal Hocko" <mhocko@...nel.org>,
        "Mike Rapoport" <rppt@...nel.org>, "Tejun Heo" <tj@...nel.org>,
        "Vlastimil Babka" <vbabka@...e.cz>,
        "Will Deacon" <will@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        page-reclaim@...gle.com, "Brian Geffon" <bgeffon@...gle.com>,
        "Jan Alexander Steffens" <heftig@...hlinux.org>,
        "Oleksandr Natalenko" <oleksandr@...alenko.name>,
        "Steven Barrett" <steven@...uorix.net>,
        "Suleiman Souhlal" <suleiman@...gle.com>,
        "Daniel Byrne" <djbyrne@....edu>,
        "Donald Carr" <d@...os-reins.com>,
        Holger Hoffstätte <holger@...lied-asynchrony.com>,
        "Konstantin Kharlamov" <Hi-Angel@...dex.ru>,
        "Shuang Zhai" <szhai2@...rochester.edu>,
        "Sofia Trinh" <sofia.trinh@....works>,
        "Vaibhav Jain" <vaibhav@...ux.ibm.com>
Subject: Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks

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