Trade-offs
Trade-offs
Posted Oct 10, 2025 4:58 UTC (Fri) by mb (subscriber, #50428)In reply to: Trade-offs by mathstuf
Parent article: Last-minute /boot boost for Fedora 43
Posted Oct 10, 2025 5:48 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (6 responses)
Posted Oct 10, 2025 6:05 UTC (Fri)
by mb (subscriber, #50428)
[Link] (3 responses)
Posted Oct 10, 2025 6:07 UTC (Fri)
by vasi (subscriber, #83946)
[Link]
Posted Oct 10, 2025 6:13 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Oct 10, 2025 6:59 UTC (Fri)
by josh (subscriber, #17465)
[Link]
Posted Oct 10, 2025 6:16 UTC (Fri)
by vasi (subscriber, #83946)
[Link]
Though this is starting to feel like we'll eventually need an extra stage of loading Linux. Eg:
Stage 1: Get to a bootloader. (Obviously there's earlier steps, but let's start here.)
Our forced-memory-resident initrd could be much smaller. Our big stage3 modules could live anywhere that Linux supports, instead of being reliant on the minimal filesystem drivers in bootloaders.
Posted Oct 10, 2025 8:24 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
I can see online that it prompts you for it via a GUI screen, but I'm not clear on whether it uses UEFI graphics, or whether it's able to load enough Windows kernel bits to run the hardware-native display driver at this point.
Put differently, are we trying to be better than Windows on the same hardware (a worthy goal, but one that can perhaps be deferred a bit), or is this a case where not using the native display driver makes us clearly worse than Windows on a given machine (where we need to be equal or clearly better to be a competitive alternative)?
Posted Oct 10, 2025 6:34 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Another reason is localization. UEFI doesn't have characters outside of ASCII. Neither does it support alternative input methods, such as on-screen keyboards.
Posted Oct 10, 2025 6:59 UTC (Fri)
by xecycle (subscriber, #140261)
[Link] (3 responses)
As for characters I think it doesn't matter if we draw characters in initramfs software; but if user decides to include special characters in their password that will be fun to support.
Posted Oct 10, 2025 11:38 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (2 responses)
File systems care, except that it mostly doesn't matter because one clicks on or copy-pastes or autocompletes these things.
Posted Oct 10, 2025 17:13 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Yes, that does mean that attackers don't have to guess whether your password uses combining or precomposed diacritical marks (assuming arguendo that your password even has diacritical marks to begin with), but that is at most a few extra bits of entropy on top of a (hopefully) much stronger password. You should not be depending on the lack of normalization for password entropy.
You might also worry that this will somehow break in a future version of Unicode, but it is actually pretty safe. The Unicode stability policy provides that, when a string contains only code points defined in version X of Unicode (for reasonably recent X), the normalization of that string according to Unicode version X will be identical to the normalization in version Y >= X. In plain English: The normalization form is not allowed to change, provided that all of the characters in the input string are mapped in the version of Unicode that you used to normalize it.
This does, however, imply that you need to scan the input string for invalid or unmapped code points, and reject them. This is far less restrictive than most password input boxes, because it still accepts every real character that anyone could use for any serious purpose, including private use characters (so we even support the people who insist on using Klingon etc. despite Unicode having rejected it multiple decades ago). Given the relative lack of stability in third-party private use standards (i.e. different organizations have proposed different private use code points for substantially or exactly identical characters), I think we would be within our rights to reject those, but it's more debatable.
I'm sure somebody will now reply and say that a key derivation function (or password hasher) should just accept raw blobs of bytes and not care about any of this Unicode nonsense. That is correct, such a function should accept arbitrary bytes and totally ignore Unicode. The above comment is not about the KDF. It is about the UI that sits in front of the KDF. That UI has to consistently turn the same text into the same bytes, or else users will get locked out of their accounts. This is exactly the same problem as "make sure the password is always UTF-8, or some other specific fixed encoding," just at a slightly higher level of abstraction.
Posted Oct 10, 2025 19:29 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Yes. That's the basic idea. The question is, however, whether everything in the stack bothers to do that.
I'm too unsure of the answer to that question being "yes" to risk adding diacriticals (or whatever) to my password. More's the pity, since that would add another fun layer to password cracking attempts (which in turn would allow me to get the same level of security with a shorter password).
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Stage 2: Load Linux and initrd into memory. We need just enough in initrd to access some real storage in early userland.
Stage 3: Initrd loads further modules from storage, for things like LUKS passwords. Eventually loads root fs and boots to full userland.
Out of interest, how does Windows handle it when it needs a Bitlocker recovery key?
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Not so for passwords.
Trade-offs
Trade-offs