All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
Date: Thu, 30 Jul 2020 13:04:15 +0200	[thread overview]
Message-ID: <941aa434-47fe-0456-54d0-4a2d70c02d08@gmx.de> (raw)
In-Reply-To: <c83bf752-5cc4-81b2-5b4f-59fef4b86e54@gmail.com>

On 30.07.20 12:16, Sean Anderson wrote:
> On 7/30/20 6:03 AM, Heinrich Schuchardt wrote:
>> Dear Sean,
>>
>> when trying to run grubriscv64.efi from the
>> trini/u-boot-gitlab-ci-runner:bionic-20200526-18Jun2020 Docker image on
>> a MAIXDUINO the relocations are not naturally aligned:
>>
>> lib/efi_loader/efi_image_loader.c(133) efi_loader_relocate():
>>
>>     efi_reloc 000000008030a000, offset 0x101e, type 10
>>
>> Here we are trying to change an u64 at 0x8030B01E:
>>
>>     uint64_t *x64 = efi_reloc + offset;
>>     *x64 += (uint64_t)delta;
>>
>> This leads to an exception in function efi_loader_relocate():
>>
>>     Unhandled exception: Load address misaligned
>>     EPC: 00000000805a95ac RA: 00000000805a953a TVAL: 000000008030b01e
>>     EPC: 000000008001c5ac RA: 000000008001c53a reloc
>>
>> The GRUB image is available here:
>>
>> https://gist.github.com/xypron/522a91962248e9c3888d8554cb61ad2c/raw/b959661626b38a738673a9efb2f398b2fabd5c77/grubriscv64.efi
>>
>> On QEMU the GRUB image is executed without problems:
>>
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/132919
>>
>> The UEFI specification requires for the ARM platform that unaligned
>> support is enabled. This is why we have implemented function
>> allow_unaligned().
>>
>> On RISC-V we have not yet implemented allow_unaligned() yet. Is there a
>> way to switch RISCV64 CPUs especially the Kendryte K210 into a mode
>> supporting unaligned access?
>
> AFAIK RISC-V has no requirement that un-aligned loads/stores complete. I
> believe the recommended solution is to install a trap handler which
> completes the un-aligned load through a series of aligned loads and then
> returns back to the application. For an example of such an
> implementation, check out arch/riscv/kernel/traps_misaligned.c in Linux.
> This may be too complex for U-Boot, so perhaps you can simply disallow
> unaligned accesses?
>
> --Sean
>

Working around the problem inside U-Boot is easy (just some memcpy()
calls) but the GRUB image itself also makes unaligned accesses:

Unhandled exception: Load address misaligned
EPC: 000000008030b004 RA: 00000000805a4eca TVAL: 000000008030b02e
EPC: 000000007fd7e004 RA: 0000000080017eca reloc

UEFI image [0x000000008030a000:0x0000000080433fff] pc=0x1004

This is what I found in "RISC-V Unprivileged ISA V20191213"

"Loads  and  stores  where  the  effective  address  is  not  naturally
aligned to the referenced datatype (i.e., on a four-byte boundary for
32-bit accesses, and a two-byte boundary for 16-bit accesses) have
behavior dependent on the EEI. An EEI may guarantee that misaligned
loads and stores are fully supported, and so the software running inside
the execution environment will never experience a contained or fatal
address-misaligned trap."

@Leif
Should GRUB be built with -mstrict-align for RISC-V?

@Ard
How about the EFI part of the Linux kernel?

Best regards

Heinrich

WARNING: multiple messages have this Message-ID (diff)
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: Sean Anderson <seanga2@gmail.com>, Leif Lindholm <leif@nuviainc.com>
Cc: Alexander Graf <agraf@csgraf.de>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	Rick Chen <rick@andestech.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	GRUB mailing list <grub-devel@gnu.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: efi_loader/RISC-V: misaligned load when running grubriscv64.efi
Date: Thu, 30 Jul 2020 13:04:15 +0200	[thread overview]
Message-ID: <941aa434-47fe-0456-54d0-4a2d70c02d08@gmx.de> (raw)
In-Reply-To: <c83bf752-5cc4-81b2-5b4f-59fef4b86e54@gmail.com>

On 30.07.20 12:16, Sean Anderson wrote:
> On 7/30/20 6:03 AM, Heinrich Schuchardt wrote:
>> Dear Sean,
>>
>> when trying to run grubriscv64.efi from the
>> trini/u-boot-gitlab-ci-runner:bionic-20200526-18Jun2020 Docker image on
>> a MAIXDUINO the relocations are not naturally aligned:
>>
>> lib/efi_loader/efi_image_loader.c(133) efi_loader_relocate():
>>
>>     efi_reloc 000000008030a000, offset 0x101e, type 10
>>
>> Here we are trying to change an u64 at 0x8030B01E:
>>
>>     uint64_t *x64 = efi_reloc + offset;
>>     *x64 += (uint64_t)delta;
>>
>> This leads to an exception in function efi_loader_relocate():
>>
>>     Unhandled exception: Load address misaligned
>>     EPC: 00000000805a95ac RA: 00000000805a953a TVAL: 000000008030b01e
>>     EPC: 000000008001c5ac RA: 000000008001c53a reloc
>>
>> The GRUB image is available here:
>>
>> https://gist.github.com/xypron/522a91962248e9c3888d8554cb61ad2c/raw/b959661626b38a738673a9efb2f398b2fabd5c77/grubriscv64.efi
>>
>> On QEMU the GRUB image is executed without problems:
>>
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/132919
>>
>> The UEFI specification requires for the ARM platform that unaligned
>> support is enabled. This is why we have implemented function
>> allow_unaligned().
>>
>> On RISC-V we have not yet implemented allow_unaligned() yet. Is there a
>> way to switch RISCV64 CPUs especially the Kendryte K210 into a mode
>> supporting unaligned access?
>
> AFAIK RISC-V has no requirement that un-aligned loads/stores complete. I
> believe the recommended solution is to install a trap handler which
> completes the un-aligned load through a series of aligned loads and then
> returns back to the application. For an example of such an
> implementation, check out arch/riscv/kernel/traps_misaligned.c in Linux.
> This may be too complex for U-Boot, so perhaps you can simply disallow
> unaligned accesses?
>
> --Sean
>

Working around the problem inside U-Boot is easy (just some memcpy()
calls) but the GRUB image itself also makes unaligned accesses:

Unhandled exception: Load address misaligned
EPC: 000000008030b004 RA: 00000000805a4eca TVAL: 000000008030b02e
EPC: 000000007fd7e004 RA: 0000000080017eca reloc

UEFI image [0x000000008030a000:0x0000000080433fff] pc=0x1004

This is what I found in "RISC-V Unprivileged ISA V20191213"

"Loads  and  stores  where  the  effective  address  is  not  naturally
aligned to the referenced datatype (i.e., on a four-byte boundary for
32-bit accesses, and a two-byte boundary for 16-bit accesses) have
behavior dependent on the EEI. An EEI may guarantee that misaligned
loads and stores are fully supported, and so the software running inside
the execution environment will never experience a contained or fatal
address-misaligned trap."

@Leif
Should GRUB be built with -mstrict-align for RISC-V?

@Ard
How about the EFI part of the Linux kernel?

Best regards

Heinrich


  reply	other threads:[~2020-07-30 11:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 10:03 efi_loader/RISC-V: misaligned load when running grubriscv64.efi Heinrich Schuchardt
2020-07-30 10:16 ` Sean Anderson
2020-07-30 11:04   ` Heinrich Schuchardt [this message]
2020-07-30 11:04     ` Heinrich Schuchardt
2020-07-30 18:31     ` Atish Patra
2020-07-30 18:31       ` Atish Patra
2020-07-30 20:11       ` Heinrich Schuchardt
2020-07-30 20:11         ` Heinrich Schuchardt
2020-07-30 20:19         ` Heinrich Schuchardt
2020-07-30 20:19           ` Heinrich Schuchardt
2020-07-30 21:10           ` Atish Patra
2020-07-30 21:10             ` Atish Patra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=941aa434-47fe-0456-54d0-4a2d70c02d08@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.