Adding Files / Directories to the ESP | GPT Disk Image | UEFI Dev (in C)
Вставка
- Опубліковано 3 лип 2024
- Making a couple functions to add files & directories to the EFI System Partition
Errata:
The paths visually show with an ending slash e.g. "Added '/EFI/BOOT/BOOTX64.EFI/'. The file is added correctly, but the path isn't ended with a null to replace the slash put in by the loop. That's fixed now in the repo, but wasn't fixed until the end of this disk image series.
Notes:
- It might be good to uppercase letters in the 8.3 directory names as well, instead of assuming the user will use only uppercase names.
Links:
uefi.org/specifications
en.wikipedia.org/wiki/Design_...
msdn.microsoft.com/en-us/wind... (EFI FAT Filesystem Spec)
UEFI Programming playlist:
• UEFI Programming in C
Next video:
- Adding command line flags/options for settings sizes of things and adding files to the ESP and Data partitions.
Git Repo:
github.com/queso-fuego/UEFI-G...
Repo state at the start of this video:
git clone -n github.com/queso-fuego/UEFI-G...
cd UEFI-GPT-image-creator
git checkout 05593d731821417859a7777d3bd37d82b218df93
Repo state at the end of this video:
git checkout ff1a4bea046fb6c6e53cc9610ecbcf107eeed38b
Join the Community Discord: / discord
Contact:
queso_fuego.srht.site/contact.html
- Let me know if there's anything specific you'd like to see!
Questions about setup/software/etc.?
Check the FAQ: queso_fuego.srht.site/about.html
Outline:
0:00 Intro / plan
6:20 Start coding, check if BOOTX64.EFI is in current directory
9:50 New function to add path to ESP
29:36 New function to add file to ESP
1:01:39 Debugging
1:09:17 Convert names to 8.3
1:22:09 Basic qemu test
1:23:57 Add dskimg.inf file to /EFI/BOOT
1:36:04 Debug making new directories in ESP
Music credits:
Winter Night by Sakura Girl | / sakuragirl_official
Music promoted by www.chosic.com/free-music/all/
Creative Commons CC BY 3.0
creativecommons.org/licenses/...
#fat32 #diskimage #cprogramming - Наука та технологія
Thanks for the video. I learnt a lot. :)
For the string comparison in add_path_to_esp, you could just do
memcmp(DIR_Name, start, (11
Oh wait nvm i forgot that DIR_Name has spaces and not null bytes at the end
There are 2 ways I can think of solving this,
1. memcpy from start to another char array with length of 11. Then compare that.
2. Make a function in assembly using the rep instruction, with rcx set to 11-strlen(start) and eax to 0x20(space char)
Then check if rcx reaches 0, if it does then it is the same, else there is something else after the initial string.
The code would be
char *aft_name = DIR_Name +strlen(start);
int length = 11-strlen(start);
asm(“ mov $0x20, %%al
mov %[name], %%rdi
mov %[len], %%ecx
rep scasb
mov %%ecx, %[len1]”:(len1)”=m”(length):(name)”m”(aft_name), (len)”m”(length):”rdi”,”ecx”);
If(length == 0) printf(“it is equal”);
I'd probably want to prevent files being added with non-8.3 compliant names when getting the command line flags, or convert file names to 8.3 at that time. That would ensure any file names are 11 length or less and prevent other issues.
Great video! Loved every second of it!🙌
Beast programmer
I'm having a weird issue with my version. I checked my gcc version and it is gcc 13.2.1. The image is created correctly on my Arch install, but with Fedora for some reason when I do a path search in my program, the first thing it should see if EFI in the struct for the dir name. However, it seems that I'm only getting 0s from the fread, and I have tested to make sure it was reading the right place. I'm not sure what is going on with Fedora to cause this issue as it also happens on Windows 11 with Mingw64.
I thought this issue was Windows only until Fedora did it as well.
Have you used a debugger and stepped through the code, or printed the values for anything used in surrounding fread(), fseek(), etc. calls? Tried xxd or a similar tool to inspect what's in the generated image at that position?
I'm not sure how to help without a repro case, as it "works on my machine", as unhelpful as that is.
Windows may have a different 'long' size, or off_t size or other types, but the image isn't larger than 4GiB so I'd think any fseeks would be fine regardless
@@QuesoFuego I manage to figure it out after a while. What ended up happening was when I was comparing the directory reads, I had coded my own memcmp function that stopped at a 0 char. Since I knew the structure would have had the next variable after the char array of dir_name in the struct, I knew that it was at least safe since it was still inside the structure. My goal was to make the GPT partitioner to not rely on std a lot. I wanted to make it possible to have the image generated without a std being toughly coupled in case I wanted to do something somewhere else like making an image in uefi. I solved it by limiting the comparison to just 11. It seems that Fedora may have had a hardened version of something that detects when you read beyond the length of the array, and it would just wipe out my array completely in my dir struct. I was able to get it to work with the fix, and I just have to be more careful of how I implement my functions.
That makes sense, I've had issues with strcmp/memcmp sometimes even when a buffer includes the null byte at the end, I've gotten segfaults and had to limit to the strlen() instead. Depends on the system, compiler, cflags, other stuff probably.
The FAT directory names, for the short names, are only 11 characters; they're 8.3 with the dot being implicit and not in the character data. That could be related to your issues.
But making your own software without depending on libc is great! The string functions can usually be pretty small, you'd have to use syscalls directly or another way to get file I/O though.
Self contained programs are awesome.
If you don't have signed size_t don't worry, you can always cast to int and then add the unary minus.
Thanks, I'll keep that in mind
Cluster Bytes Fats. Sounds like an eating disorder.
You remember the freshman 15, now try the FAT32!
@@QuesoFuego 🤣😂😆
Do you really need "." and ".." directories? The kernel should know current directory and parent directory without these directories?
There could be some firmware that doesn't care, I'm just following the docs
@@QuesoFuego okay thanks
@@hampus23 At least for QEMU/OVMF, it doesn't seem to matter that much, the UEFI shell works for paths in the ESP either way, although mkdir does add . and .. entries to new directories.
@@QuesoFuego okay, do you know if this is for FAT only or is it the same for EXT?
I only know for FAT, I'm not aware of any UEFI firmware that has ext/2/3/4 drivers, there may be some out there.
It would depend on the specific file system driver, if it evaluates the . and .. and requires those specific directory entries or not