I appreciate Plug-and-Play USB Keys.

I am used to an older time, when the stores did sell customers USB Drives / Keys, which were formatted with NTFS, and which, if we inserted them into our Linux PCs, would not mount. Today, the USB Keys we buy, can in some cases be plug-and-play, with modern Linux computers.

But the gap that once existed here, mainly existed between what a Linux computer could mount from the command-line, and what the desktop manager / HAL daemon was willing to mount, simply because the user plugged it in.

For example, I can perfectly-well format my USB Pen Drive to the ‘ext4‘ file system, but then the desktop manager would not accept that, because to do so would imply a security violation. It would effectively give any user ‘root‘, because any ext4 content could be stored as root, with ‘setiud, and be as the user provided. And yet, with the root password, it would still be possible to mount that…

There is a word of caution I should give fellow computer users though. Whichever computer you are on – be it Windows, OSX, Linux or other – you should still assume that if you mount a file system other than one native to your O/S, it will be mounted without journaling enabled. This means, that we will need to be extra careful, not to pull the key out, without first having done an explicit Safe Disconnect / Unmount.

It is the file system journal which will ensure, that only files are lost or damaged, which we were editing, and if so, atomically altered. Without this in place, we can end up with a USB Key which will only mount again explicitly in read-only mode, which also means that we will need to reformat again, before we can write new data to it. Hence, with no journaling, if the USB Key is pulled out while active, we could lose the whole content – although that is not usually what happens.

And so it could be said that Linux kernels as early as 2.4 had some ability to mount NTFS file systems, it would have been premature to say that those would be fully compatible with the USB Key, as provided, just because the desktop managers did not mount it. Even though they could already be mounted from the command-line.

I guess that the people who configure Linux these days, have figured out, that for their desktop manager to auto-mount an NTFS volume, does not present a security risk.

There does exist a type of NTFS driver under Linux, which will do an NTFS mount, more the way Windows does NTFS. It is called ‘ntfs-3g‘. But the only real purpose of that is to allow the owners of dual-boot laptops, to mount their Windows partitions from within Linux, which remains the only easy way to exchange data between Linux and Windows sessions. ntfs-3g was not meant for USB Keys, nor for automatic service from HAL.

Speaking of which: I just needed to trash a USB Key. I was able to mount it under Linux, and then to save a folder of data to it, which seemed to join the already-present folders in ‘Dolphin‘. But after that, whenever I removed the USB Key and remounted it, all the changes I had made were just gone. It seemed as though they had been cached, and with the cache cleared, the actual mass-storage device did not remember anything. This was accompanied by some very strange error messages, whenever I tried to repair the old key with software tools.

And so at some point I had to acknowledge that either the H/W had to have become defective, or that I had done so much reformatting, that I could reformat the little thing no more. Scientifically, the second option makes less sense, because no matter how many times one reformats the key back to FAT32 finally, its configuration should go back to one that at least works, even if it can only handle up to 40GB total. Mine would not recover into this state.

And it should also have been possible to format it with ‘etx2‘ on one specific Linux computer, to store data on that partition, to remove, reinsert and then remount the key on the same computer, and to retrieve the data. This experiment had also failed, at the point where the key had been remounted but failed to show the new data.

So now I have a brand-new USB key with a capacity for 128GB, which is plug-and-play compatible with my Linux boxes, and which remembers everything I stored on it (Insert Evil Scientist Laugh Here.)

I did not even bother to open it with ‘gparted‘ first, just to satisfy my curiosity. I do not care what FS they used. I just tried plugging it in, and it worked. And my two main Linux machines are on exactly the same build.

I had bought the old USB Key, before this present computer – ‘Phoenix’ – was installed, when its hardware was host to a system I had named ‘Thunderbox’. And Thunderbox was not able, to mount that older USB Key directly.

However, that USB Key was useful to me, in migrating some of my data, around the time that I was reinstalling ‘Aphrodite’ as ‘Venus’, and ‘Thunderbox’ as ‘Phoenix’. The key was formatted with FAT32 and held its data at the time. But what I really wanted today was a full-capacity USB Key, not limited to 40GB.

I would bet, that if I had re-partitioned it with FAT32 using my Windows PC, it would have played its old game with me: Of seeming to store data for a longer time, but then just forgetting it again.

What I needed was a new USB Key, which I now have.


(Edit 06/06/2016 : ) I just found out, that what Sony did, was just to format this new USB Key with FAT32.

A part of that which I do not understand, and which contributed to my initial confusion, was my memory to the effect that, FAT32 file systems were once not allowed to be bigger than 40GB. But this is a 128GB stick. I do not understand this.


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…