flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Format options for UEFI OS bootloader

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
sinsi



Joined: 10 Aug 2007
Posts: 794
Location: Adelaide
sinsi 26 Oct 2023, 23:34
You can download the UEFI spec from https://uefi.org/specsandtesttools
Post 26 Oct 2023, 23:34
View user's profile Send private message Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 27 Oct 2023, 01:23
I meant, where in the UEFI specification is written that an OS bootloader must be treated as a FASTCALL routine? Because it sounds strange to me (I would transfer control with a jump, there is no need for a call): it may be common practice now but not in the future.
For example, it's common to think that a CD image can always be in ISO format, but UEFI doesn't think so and only mandates UDF format, so VirtualBox dropped ISO support in UEFI.


Last edited by pfranz on 27 Oct 2023, 01:29; edited 1 time in total
Post 27 Oct 2023, 01:23
View user's profile Send private message Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 27 Oct 2023, 01:28
sinsi wrote:
You can download the UEFI spec from https://uefi.org/specsandtesttools
Thanks, I already have 2.10 specification, I thought I had caught the most important things, but it doesn't seem so.
I cannot find where it says that an OS bootloader must be called according to the fastcall specification. Why not use a simple jump?
Post 27 Oct 2023, 01:28
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20454
Location: In your JS exploiting you and your system
revolution 27 Oct 2023, 02:26
pfranz wrote:
Why not use a simple jump?
Firstly because it wouldn't comply with the spec. But also because it is designed around c (or c++, or other HLLs) where specifying custom calling conventions per function is frowned upon unless there is some necessary reason.
Post 27 Oct 2023, 02:26
View user's profile Send private message Visit poster's website Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 794
Location: Adelaide
sinsi 27 Oct 2023, 02:50
Post 27 Oct 2023, 02:50
View user's profile Send private message Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 28 Oct 2023, 13:27
sinsi wrote:
Not sure if you need a GPT disk and/or an EFI System partition (type 0xEF) for booting
The following code will boot in Virtual Box 7 (from a VHD with GPT and EFI System partition)
Code:
format pe64 efi
section '.text' code executable readable

entry $
                sub     rsp,28h
                mov     rcx,[rdx + 64]
                mov     rax,[rcx + 8]
                mov     rdx,string
                call    rax
                jmp     $

string du 'Hello, World!',13,10,0
    
I read in the spec that GPT requires an EE protective MBR and cannot coexist with an EF system partition.
Could you please post the VHD of this example? I tried creating a VHD myself, another using GParted, but I always end up in the UEFI shell and have to manually boot from file. VirtualBox version is 6.1.48.
Post 28 Oct 2023, 13:27
View user's profile Send private message Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 794
Location: Adelaide
sinsi 28 Oct 2023, 14:08
I'm using VirtualBox 7.0.8, so ymmv


Description:
Download
Filename: UEFI.7z
Filesize: 559.48 KB
Downloaded: 238 Time(s)

Post 28 Oct 2023, 14:08
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 514
Location: Czech republic, Slovak republic
Feryno 28 Oct 2023, 18:21
pfranz wrote:
Code:
        mov     rdx,string
...
string du 'Hello, World!',13,10,0
    


use this:
Code:
        lea     rdx,[string]    


That's because when uefi finds the base address specified in your binary already used, it relocates binary to different base address - the solution is to use relocs or to use RIP-relative addressing mode which works no matter at which base address is the binary relocated.

Did you try to create FAT12 formatted 1,44 MB floppy image and put you program into \EFI\BOOT\bootx64.efi ? Yes hdd image should be GPT formatted (you can use e.g. linux for creating and accessing such image), so floppy image seems to be much easier to create / write file there.
Post 28 Oct 2023, 18:21
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 30 Oct 2023, 03:46
I tried sinsi's harddisk image and it didn't work. After a lot of experimenting, it turned out that it was some kind of misconfiguration in VirtualBox, that wouldn't be fixed by reinstalling it and deleting the virtual machines directory.
So I reinstalled Linux and both sinsi's and my hard disk image worked straightaway in VirtualBox 6.1.48 and 7.0.12.

My disk image has just a legacy mbr with only one EF partition from lba1 to the end. I create the partition with mkfs.msdos -C, I mount it, I copy the uefi files, I unmount it, I append mbr and vhd sections, and it works.

I tried with the diskette image but apparently uefi doesn't even see the volume.
Post 30 Oct 2023, 03:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20454
Location: In your JS exploiting you and your system
revolution 30 Oct 2023, 05:10
pfranz wrote:
So I reinstalled Linux ...
That is/was always the "solution" to problems with Windows. So now we can finally say that Linux has reached feature parity with Windows. Razz
Post 30 Oct 2023, 05:10
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 30 Oct 2023, 19:02
Feryno wrote:
Did you try to create FAT12 formatted 1,44 MB floppy image and put you program into \EFI\BOOT\bootx64.efi ? Yes hdd image should be GPT formatted (you can use e.g. linux for creating and accessing such image), so floppy image seems to be much easier to create / write file there.
The floppy image seems to be exactly the problem.
After reinstallation, my legacy MBR EF hard disk image worked fine. I prepared a CD image with no emulation EF partition as per specification, it booted too. Everything was working flawlessly.
Then I built a 1.44 floppy image the way you described (that is how I did the hd and cd partitions), tried to boot from it, UEFI found no map and didn't even see it.
Removed floppy controller, attached hard disk and cd. None of them works now: they drop into the shell and I have to launch bootx64.efi manually, using "Boot from file".
By the way, where does VirtualBox keep its configuration? I deleted the virtual machines and /etc/vbox directories, but still remembers my machine on reinstallation.
Post 30 Oct 2023, 19:02
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20454
Location: In your JS exploiting you and your system
revolution 30 Oct 2023, 19:54
pfranz wrote:
By the way, where does VirtualBox keep its configuration?
IIRC here:
Code:
${HOME}/.config/VirtualBox/VirtualBox.xml    
Post 30 Oct 2023, 19:54
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 31 Oct 2023, 05:11
Feryno wrote:
Did you try to create FAT12 formatted 1,44 MB floppy image
Did you? Did it work? If so, can you post the floppy image, please?
Post 31 Oct 2023, 05:11
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 514
Location: Czech republic, Slovak republic
Feryno 31 Oct 2023, 10:18
pfranz - I didn't. It is an idea which may help you to track the problem. I work directly on hardware and not on emulators. I execute 'efi' app from USB stick under uefi shell and I start 'efiboot' from hdd (GPT formatted with EFI system partition) after writing necessary nvram variables (BootXXXX, BootOrder).
You can create such floppy in a way like this:
dd if=/dev/zero of=./fd.img bs=512 count=2880
mkfs.msdos ./fd.img
mkdir /mnt/floppy
mount ./fd.img /mnt/floppy -o loop
mkdir /mnt/floppy/EFI
mkdir /mnt/floppy/EFI/BOOT
cp mybinary.efi /mnt/floppy/EFI/BOOT/bootx64.efi
umount /mnt/floppy


Description:
Download
Filename: fd_uefi.zip
Filesize: 29.02 KB
Downloaded: 239 Time(s)

Post 31 Oct 2023, 10:18
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 01 Nov 2023, 04:12
Feryno wrote:
pfranz - I didn't. It is an idea which may help you to track the problem. I work directly on hardware and not on emulators. I execute 'efi' app from USB stick under uefi shell and I start 'efiboot' from hdd
I asked because I think an EFI system is not supposed to boot from a floppy (too old of a device), so probably the VirtualBox team didn't bother to make floppies visible to EFI.
I had built my image exactly as you described (save that I use mkfs -C option instead of dd), and your image is not seen at all, like mine.
Have you ever booted a real efi system from floppy, or know someone who did?
Post 01 Nov 2023, 04:12
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 514
Location: Czech republic, Slovak republic
Feryno 01 Nov 2023, 11:44
I tried just now with vmware workstation 16 and the floppy image works well
If you manage to make the floppy image to work, you can copy there your executable and debug it (there is uefi debugger). These commands:
s single step
t trace over
g run
c code dump
h help


Description:
Filesize: 53.5 KB
Viewed: 5965 Time(s)

uefi_floppy.png


Description:
Filesize: 56.26 KB
Viewed: 5965 Time(s)

uefi_floppy_fdbg.png


Post 01 Nov 2023, 11:44
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 02 Nov 2023, 23:50
Feryno wrote:
I tried just now with vmware workstation 16 and the floppy image works well
VMware looks buggy. 17.5.0 and 16.2.5 don't install (for different reasons) and 15.5.7 installs but crashes on a legitimate VESA call in legacy BIOS boot.
Anyway I don't think I need to debug EFI applications, but with 15.5.7 I couldn't find how to use EFI.
Thanks for your suggestions, though.
Post 02 Nov 2023, 23:50
View user's profile Send private message Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 514
Location: Czech republic, Slovak republic
Feryno 03 Nov 2023, 03:59
That's why I'm still using 16.1.0 build-17198959 because I read that 16.2 disabled mounting hard disk images into host OS so I did not update to newer versions since then.
Bugs are everywhere, especially in such big product like this. VmWare ESXi uses also the same hypervisor and it was possible to completely crash VM in ESXi 6.7 on an attempt to start a child hypervisor inside VM with disabled (!) CR8 load exiting on Intel CPU, surprisingly it ran well with this feature enabled (just with much worse performance due to much more unwanted vm exits). They luckily fixed it in ESXi 7.
Post 03 Nov 2023, 03:59
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
bzt



Joined: 09 Nov 2018
Posts: 79
bzt 17 Jan 2024, 09:46
pfranz wrote:
I meant, where in the UEFI specification is written that an OS bootloader must be treated as a FASTCALL routine?
UEFI spec section 2.3.4.2. Detailed Calling Conventions. Strictly speaking the spec calls it "EFIAPI", but if you compare it with fastcall, you'll see that they are identical.
pfranz wrote:
Because it sounds strange to me (I would transfer control with a jump, there is no need for a call): it may be common practice now but not in the future
This will remain and won't change in the future. A jump won't cut it as you should always be able to return from an "efimain" function of an OS bootloader, which is an UEFI Application. See UEFI spec StartImage().
pfranz wrote:
I read in the spec that GPT requires an EE protective MBR and cannot coexist with an EF system partition.
Neither of these are true. EE protective MBR isn't mandatory (think about it, it's impossible to do it with more than 2^32 sectors anyway), and EF not just can coexists with GPT ESP, but they can point to the very same partition (there's not much point in doing so, but possible and valid according to the spec).
pfranz wrote:
My disk image has just a legacy mbr with only one EF partition from lba1 to the end. I create the partition with mkfs.msdos -C, I mount it, I copy the uefi files, I unmount it, I append mbr and vhd sections, and it works.
You could do all of this with a single command. No root privilege required like with your mount method. It also creates a GPT and a PMBR as well (although the latter uses 0C and not EF for backward compatibility, EF not needed as UEFI reads the GPT anyway, and it doesn't even bother to parse the legacy partitions when GPT is found).
pfranz wrote:
I asked because I think an EFI system is not supposed to boot from a floppy
No, it does not. First, UEFI spec section 10.3.5. Media Device Path, there's no means to describe a floppy device under UEFI. Second, UEFI spec section 13.3 File System Format. It says "EFI encompasses the use of FAT32 for a system partition". It talks about "partition", and the minimum size of FAT32 is 33Mb, which simply does not fit on a floppy. It also mentions that "and FAT12 or FAT16 for removable media", but firmware very rarely implement those, you're lucky if FAT16 is supported, and it's a miracle if you can find a firmware with FAT12 support. Mostly only VMs support non-32 FAT, but not real hardware.
Post 17 Jan 2024, 09:46
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.