linux-kernel - Re: [PATCH] LoongArch: Make -mstrict-align be configurable

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 06 Feb 2023 11:33:10 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Huacai Chen" <chenhuacai@...nel.org>
Cc:     "Huacai Chen" <chenhuacai@...ngson.cn>, loongarch@...ts.linux.dev,
        Linux-Arch <linux-arch@...r.kernel.org>,
        "Xuefeng Li" <lixuefeng@...ngson.cn>, guoren <guoren@...nel.org>,
        "WANG Xuerui" <kernel@...0n.name>,
        "Jiaxun Yang" <jiaxun.yang@...goat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] LoongArch: Make -mstrict-align be configurable

On Fri, Feb 3, 2023, at 03:08, Huacai Chen wrote:
> On Thu, Feb 2, 2023 at 5:47 PM Arnd Bergmann <arnd@...db.de> wrote:
>>
>> On Thu, Feb 2, 2023, at 09:42, Huacai Chen wrote:
>> > Introduce Kconfig option ARCH_STRICT_ALIGN to make -mstrict-align be
>> > configurable.
>> >
>> > Not all LoongArch cores support h/w unaligned access, we can use the
>> > -mstrict-align build parameter to prevent unaligned accesses.
>> >
>> > This option is disabled by default to optimise for performance, but you
>> > can enabled it manually if you want to run kernel on systems without h/w
>> > unaligned access support.
>> >
>> > Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
>>
>> This feels like it's a way too low-level option, I would not expect
>> users to be able to answer this correctly.
>>
>> What I would do instead is to have Kconfig options for specific
>> CPU implementations and derive the alignment requirements from
>> that.
> You mean provide something like CONFIG_CPU_XXXX as MIPS do?  That
> seems not a good idea, too. If there are more than 3 CONFIG_CPU_XXXX,
> the complexity is more than CONFIG_ARCH_STRICT_ALIGN.

The way that mips does it is not useful since that forces you to
pick a single CPU from a 'choice' list in Kconfig, with the CPUs
being mutually exclusive in that list. What you need here is either
a strict hierarchy of CPUs like in arch/x86/Kconfig.cpus where each
option is a superset of the previous one, or a set of options
like in arch/arm/mm/Kconfig that are not mutually exclusive and
let you pick any combinations that you want to support in a kernel
image.

The important bit is that a kernel you build will by default
always work across all hardware except the ones that are
explicitly excluded.

> Then users are also unable to do a correct selection. On the other
> hand, we can add more words under CONFIG_ARCH_STRICT_ALIGN to
> describe which processors support hardware unaligned accesses.

Trying to handle this with help texts quickly gets out of hand
when you get to dozens of CPU specific optimizations that are
incompatible with other CPU cores. I assume you will need similar
options e.g. for the broken cpu-idle instruction on early cores
or the missing sub-word atomics, once these are fixed in new
CPU cores.

     Arnd