Bug 240572

Summary:	libefi: FreeBSD cannot boot with U-Boot patch efi_loader: parameter checks BLOCK_IO_PROTOCOL
Product:	Base System	Reporter:	Heinrich Schuchardt <xypron.glpk>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	emaste, kevans, manu, tsoome, xypron.glpk
Priority:	---	Keywords:	needs-qa
Version:	CURRENT	Flags:	koobs: mfc-stable12? koobs: mfc-stable11?
Hardware:	Any
OS:	Any
URL:	https://reviews.freebsd.org/D21655

Description Heinrich Schuchardt 2019-09-13 21:54:58 UTC

Booting current FreeBSD fails since patch
f59f0825e8b9fdeb8abe43ffd10c5119ca1a032f
efi_loader: parameter checks BLOCK_IO_PROTOCOL

The reason is that the buffer used by FreeBSD to read is not block aligned.

The UEFI spec requires that EFI_BLOCK_IO_PROTOCOL.ReadBlocks() returns
EFI_INVALID_PARAMETER if the buffer is not properly aligned (i.e. is not
a multiple of EFI_BLOCK_IO_MEDIA.IoAlign)

FreeBSD does not guarantee this alignment, e.g. efi_disk_read_blocks()
is called with buffer 00000000995b08d0 which is not aligned to a
multiple of 512.

FreeBSD function efipart_readwrite writes this error message:
efipart_readwrite: rw=1, blk=62333952 size=1 status=2

The problem can be traced back to the FreeBSD line:

stand/efi/libefi/efipart.c(1043) efipart_realstrategy():
blkbuf = malloc(blkio->Media->BlockSize);

U-Boot does not yet implement the EFI_DISK_IO_PROTOCOL which is a
wrapper for the EFI_BLOCK_IO_PROTOCOL allowing unaligned access.

malloc() could be replaced in FreeBSD by AllocatePages() which returns a
4096 byte aligned memory block.

Comment 1 Kyle Evans freebsd_committer

2019-09-14 02:22:54 UTC

I've opened this up: https://reviews.freebsd.org/D21655

Comment 2 Heinrich Schuchardt 2019-09-19 20:55:01 UTC

Commit 16ef880ce6ee ("loader.efi: efipart needs to use ioalign") was merged into FreeBSD on Sep 17th, 2019.

Comment 3 Ed Maste freebsd_committer

2019-12-10 21:16:41 UTC

Fixed by r352446?

Comment 4 Emmanuel Vadot freebsd_committer

2020-09-17 09:30:17 UTC

(In reply to Ed Maste from comment #3)

Yes it's fixed.
Closing this now.