the oldest trick in the book 😅

nixCraft's posts Post Back to profile

nixCraft 🐧

The meme features a character with a sly expression. The text says, "It's NOT vendor lock-in" about Secure Boot and then suggests saying, "It's for security reasons!" This implies that Secure Boot, a technology that restricts what operating systems can run on a device, is being used to lock users into a specific vendor despite claims that it's for security. The character's sly look hints that certain evil corporations are doing this deceptively and on purpose.

Like 20 December at 21:46 | Open on mastodon.social

17 comments

Paul_IPv6

@nixCraft

"it's not vendor lock-in. it's an exclusive security feature!"

20 December at 21:47 | Open on infosec.exchange

kuba86

@nixCraft
Can you provide more info on how UEFI secure boot is a vendor lock in? I have been using it on Fedora and seen it on Arch Linux, Debian etc.

20 December at 21:53 | Open on mas.to

𝔱𝔯𝔷𝔶𝔤𝔩𝔬𝔴 :lattentacle:

@kuba86 @nixCraft at least on arch you can't get secure boot to work reliabily, if you are not using microsoft's proprietary keys as an additional dataset. (don't know how things are handled regarding this on other distros)

20 December at 22:15 | Open on mastodon.social

Uriel Fanelli

@kuba86 @nixCraft The filesystem is a patent of Microsoft.

## FAT32: Microsoft Patent Status and Open Source Implications
FAT32 is a file system developed by Microsoft, but its patent and open-source status is complex:

### Patent Ownership

1. Microsoft holds patents on certain aspects of the FAT file system, including FAT32
2. These patents have been subject to legal challenges in various countries
3. Microsoft has granted royalty-free licenses for FAT use in some contexts

### Open Source Considerations

1. Basic FAT32 specifications are widely known and implemented in open-source systems like Linux
2. Open-source implementations exist but might potentially infringe Microsoft patents
3. Not truly "open source" in the traditional sense due to patent restrictions

### Practical Usage

- Widely used for universal storage compatibility
- Implemented across multiple operating systems
- Commonly used for removable storage devices and UEFI system partitions

### Legal Nuances

- Patent validity and enforcement vary by jurisdiction
- Some implementations exist in a legal "gray area"

The bottom line: FAT32 is technically proprietary but practically widely accessible, with Microsoft maintaining theoretical patent control.

Expand text...

20 December at 22:51 | Open on x.keinpfusch.net

Desdinova

@uriel @kuba86 @nixCraft FAT related patents expired years ago.

yesterday at 2:17 | Open on mastodon.social

kuba86

@Eternal_Light @uriel @nixCraft
Most of what I was able to find online are issues around getting a digitally signed boot loader. Linux distros needs to pay Microsoft for having that "out of the box" experience. Microsoft is a CA in this case. However, in bios I can load any key so in theory, Fedora or any other distro could distribute their own key which users could load and no longer depend on Microsoft.
Of course that's not very user friendly.

yesterday at 6:51 | Open on mas.to

Uriel Fanelli

@kuba86 @Eternal_Light @nixCraft UEFI is using exfat32. Microsoft patent. It is a fact. What you find online is just how good you are at googling, is not relevant.

yesterday at 6:58 | Open on x.keinpfusch.net

Uriel Fanelli

@Eternal_Light @kuba86 @nixCraft nope.

yesterday at 6:59 | Open on x.keinpfusch.net

𒀹insignificant thoughts𒀺

Sensitive content

@nixCraft What exactly is the issue with secure boot itself? Just the fact that microsoft keys come preinstalled? I can install my own keys on any board I have used, are there any that do not allow that?

20 December at 21:55 | Open on uwu.social

Lenni :linux: :starfleet:

@InsignificantThoughts @nixCraft Sadly there are. Some motherboards (mostly cheaper laptops) don't even allow you to disable secure boot entirely.

20 December at 22:10 | Open on fosstodon.org

mikeTesteLinux

@Lenni @InsignificantThoughts @nixCraft Maby, but we can install a key with mok to work around that (like @InsignificantThoughts said), so I don't see the problem (I can disable on mine, but I've created a key, and my nvidia driver work fine) and my secure boot is enabled.

20 December at 23:54 | Open on mastodon.social

Andy

@nixCraft can someone help me make this argument apply for Rust? no, Rust is like C/C++...! no, monadss, or something... :(

20 December at 22:30 | Open on mastodon.social

Desdinova

@nixCraft Meanwhile, in the real world, Debian has a strongly worded article about how UEFI and Secure Boot actually are for security reasons and that, on a Linux only system, you can wipe the default keys and install keys from that Linux distro.

UEFI is close to 20 years old at this point, and Secure Boot is part of the spec. If Microsoft was going to do something nefarious, they'd have done it by now. Instead, they require OEMs to have unlockable firmware.

https://wiki.debian.org/SecureBoot

yesterday at 2:14 | Open on mastodon.social

フェリックスたん

@Eternal_Light@mastodon.social @nixCraft@mastodon.social with the assumption that the firmware supports user-defined variables/keys

there are x86 models that enforce SB and TPM with only MS key and Vendor key

one can't even revoke a known exploited key.