linux-kernel - Re: [PATCH 2/2] riscv: uaccess: do not do misaligned accesses in get/put

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: <ff60e791-7305-4ea8-8048-ff33316bf8f1@rivosinc.com>
Date: Mon, 2 Jun 2025 09:35:30 +0200
From: Clément Léger <cleger@...osinc.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>,
 David Laight <david.laight.linux@...il.com>
Cc: linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 Alexandre Ghiti <alex@...ti.fr>
Subject: Re: [PATCH 2/2] riscv: uaccess: do not do misaligned accesses in
 get/put_user()

On 01/06/2025 19:35, Maciej W. Rozycki wrote:
> On Sat, 31 May 2025, David Laight wrote:
> 
>>> Such behavior was detected with GET_UNALIGN_CTL() that was doing
>>> a put_user() with an unsigned long* address that should have been an
>>> unsigned int*. Reenabling kernel misaligned access emulation is a bit
>>> risky and it would also degrade performances. Rather than doing that,
>>> we will try to avoid any misaligned accessed by using copy_from/to_user()
>>> which does not do any misaligned accesses. This can be done only for
>>> !CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS and thus allows to only generate
>>> a bit more code for this config.
>>
>> For get_user() you are much better off reading the two words that contain
>> the value and then doing 'shift' and 'or' to get the correct value.
>>
>> Even for put_user() doing the explicit byte accesses will be faster than
>> going though the generic copy_to/from_user() function.
> 
>  FWIW I think optimising copy_to/from_user for such cases would be a more 
> robust approach moving forward than sprinkling open-coded implementations 
> across code.

Hi Maciej,

Indeed, that's a good idea, we could optimize small copy in
copy_from/to_user so that will benefit all the users as well.

Thanks,

Clément

> 
>   Maciej