linux-kernel - Re: [PATCH v3 1/8] riscv: Avoid unaligned access when relocating modules

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] [day] [month] [year] [list]

Date:   Mon, 28 Feb 2022 13:46:00 +0100
From:   Emil Renner Berthing <emil.renner.berthing@...il.com>
To:     Samuel Bronson <naesten@...il.com>
Cc:     linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/8] riscv: Avoid unaligned access when relocating modules

On Mon, 28 Feb 2022 at 01:45, Samuel Bronson <naesten@...il.com> wrote:
>
> Emil Renner Berthing <kernel@...il.dk> writes:
>
> > With the C-extension regular 32bit instructions are not
> > necessarily aligned on 4-byte boundaries. RISC-V instructions
> > are in fact an ordered list of 16bit native-endian
> > "parcels", so access the instruction as such.
>
> Hold on a minute, this is what it says in my copy of the Unprivileged
> ISA:
>
> ,----
> | RISC-V base ISAs have either little-endian or big-endian memory systems,
> | with the privileged architecture further defining bi-endian operation.
> | Instructions are stored in memory as a sequence of 16-bit *little-endian*
> | parcels, regardless of memory system endianness.  Parcels forming one
> | instruction are stored at increasing halfword addresses, with the
> | *lowest-addressed parcel holding the lowest-numbered bits* in the
> | instruction specification.
> `----
> [Emphasis mine.]
>
> In other words, the parcels are little endian, and they're arranged in
> little-endian order.  System endianness doesn't matter, it collapses to
> plain old little-endian.

Wow, this actually changed since I wrote this code, nice catch. In
specs up until the latest it used to say "Instructions are stored in
memory with each 16-bit parcel
stored in a memory halfword according to the implementation’s natural
endianness". I hope noone designed a big-endian core before they
changed it.

> (I'm really not sure why they describe the ordering in such a
> round-about way; I assume that's the source of the confusion here?)

I guess the round-about way is exactly because the parcels used to be
native-endian, but the order of the parcels alsways little-endian.

/Emil