An Observation about the UEFI FAT32 Partition

In This Posting, I remarked that I had wiped the laptop I named ‘Maverick’, and replaced its Windows 8.1 O/S with a UEFI-enabled Linux, resulting in a computer I now name ‘Klystron’. This is a healthy computer which has a long road ahead of it, including any software I need to install.

But before I wiped ‘Maverick’, I did have a look at it with the Linux partition management tool named ‘gparted’. I found that Maverick had numerous partitions, for which there was no drive letter, which it came shipped with from the seller.

Those original partitions included one, which was a FAT32, and which performed the same function as the FAT32 partition does, that is needed for a UEFI-capable Linux install. So there is no system-software reason, for which the BIOS would treat my FAT32 partition any differently, from how it treated the original one.

That partition has a subfolder, which contains an .EFI File, which is ultimately the boot-loader.

It is possible for these compiled, binary EFI Files to contain statically-linked EFI signatures. Only, because these signatures cannot be found loosely in some sort of bin, it also follows that if the signature in question forms a chain, such a cryptographic chain needs to be complete in itself, and must lead to its master key, which is white-listed by the BIOS.

(Edit : ) The practical consequence of this would have been, that If we wanted to set up dual-boot, it would be feasible after all, first to allow our Windows setup-disk partition the HD, but to tell this setup-disk only to use the space partially, leaving the rest unallocated. After Windows set itself up, the next step would have been, to set up Linux ourselves, and to allow Linux to avail itself of the FAT32 partition, which Windows left.

The reason I still did not go this route, was the fact that on Maverick, the Windows partition was already almost half in use. I do not think it would have been safe, to tell ‘gparted’ just to shrink one of its NTFS partitions, because there have been compatibility issues, between how Windows and Linux implement NTFS. It has happened to me in the past, that I told ‘gparted’ to shrink even an ‘ext4′ file system (that belonged to Linux), and that having done so left that file-system unusable.

So the NTFS partitions on Maverick had their final size, while using up most of my HD space. And so to make a dual-boot machine, would also have required a fresh install of Windows, which was out of reach for the moment.

(Edit : ) I am noticing some fog about the subject, of whether it is possible to find not only executable EFI Files, but also Keys, in this FAT32 partition, which is also referred to as the EFI System Partition, or “ESP”. The issue I read arises here:

Quoted Article

The main problem I see with this, is the idea that public keys can simply be dropped into this partition, without themselves needing to be signed by the Master Private Keys, making those self-signed. The idea that this exists, strikes me as a massive security hole in Secure Boot…

(Edit : ) It turns out that the world is not such a strange place after all. Reading further down in the above article, I found that the only purpose in storing the Keys in the FAT32 partition, the ‘ESP’, was to make them visible to the BIOS before the O/S has loaded, so that we can tell our BIOS to Clear the previous Keys, and then to Set new Keys.

So the firmware must be told the new keys after all… This makes more sense…



Microsoft has Not actually Excluded Linux from UEFI.

This posting was the result of an error on my part, which led to more errors, in more postings.

My problem was, that even though the Linux version in question can be installed in UEFI mode, doing so without the Secure Boot option, disables all cryptographic checks on the booted image. Doing so simply installs the Linux version to use the UEFI BIOS system rather than Legacy, but without providing any EFI signatures for the image.

I apologize for the error.



Kanotix makes it easy, to install a Linux version on a UEFI motherboard.

The Linux versions I have stayed with in my past, are Kanotix versions. This does not change the fact that they are Debian-based; it only means that the Kanotix Team has simplified the packaging of a specific Debian system, so that it is ready to go.

Kanotix Dragonfire -> Debian / Wheezy (obsolete),

Kanotix Spitfire -> Debian / Jessie (actual).

Kanotix can be found here.

I have never had to do this. But if we wanted to install Linux on a UEFI-BIOS Motherboard, Kanotix makes it easy. They have a fabled installer called their ‘Acritox Installer’, which allows the user to specify an arbitrary part of the file system, which should be mounted from non-root disk partitions. Typically, this was done with the ‘/home‘ mount-point, using a Linux-oriented file system, such as ‘ext4‘. But for UEFI, we need to tell Acritox, to makeĀ  custom, FAT32 mount-point at ‘/boot/efi‘ , which therefore has its own partition.

The fact that this needs to be done, implies that this partition, which will either need to be a ‘Primary MBR’ or ‘Any GPT’ partition, will be readable by the BIOS, even before the O/S boots. This is the logical place where the O/S will store the signatures, of all the Images which are supposed to be bootable. Hence, there has been no special change to the format, in which the actual ‘initramfs‘ images are stored, but rather, every time we do an ‘update-initramfs‘, doing so will also add an entry to this FAT32 partition, for the newly-added image.

(Edit 04/05/2016 : ) According to the fact that I have discovered a major error in my thinking, it is also a fact, that this partition does not really store EFI signatures…