Microsoft is doing a hit piece on GRUB2 and shilling its AI https://www.microsoft.com/en-us/security/blog/2025/03/31/analyzing-open-source-bootloaders-finding-vulnerabilities-faster-with-ai/

"Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation" Fuck you

«While threat actors would likely require physical device access to exploit the U-boot or Barebox vulnerabilities, in the case of GRUB2, the vulnerabilities could further be exploited to bypass Secure Boot" Good, nobody wants that piece of garbage

The "vulnerabilities" they listed occur in filesystems like ReiserFS and JFS... who the fuck uses those filesystems?

@hfaust
Aside a marketing stunt, one must ask himself why would Microsoft analyses anything but itself ?

@mangeurdenuage Microsoft has investigated itself and found no wrong.

@hfaust

@hfaust People who did nothing wrong.

@hfaust oh boy I know where this is going.

@hfaust You can tell it's a hit piece from the title, considering the massive insult of calling GNU Grub an "open source" bootloader.

@hfaust Of course they never name the GNU (there would be no mention of GNU if it wasn't for the 2 gnu.org URLs).

>extend our analysis to other bootloaders like U-boot and Barebox, which share code with GRUB2
Considering you cannot combine GPLv3-or-later with GPLv2-only, this doesn't seem correct.

They also write about "saving a weeks worth of time", but they've clearly wasted more than a weeks worth of time filing pointless CVEs (which are only useful if you want to embarrass a proprietary software developer into fixing bugs).

>The dangers of a GRUB2
>Since bootloaders run before operating systems run
Of course it's sooo dangerous to run GRUB and GRUB isn't an OS.

If you want NX, ASLR, pointer authentication or stack cookies/canaries, it's simply a matter of enabling that in GCC or implementing it in the GRUB OS.

>Suggestion of completely junk integer overflow detection like; if (size + 1 < size)
It looks convincing, but those sort of checks *do not work*.

The only working way to detect integer overflow is to use a compiler built-in like; __builtin_add_overflow https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

https://git.savannah.gnu.org/cgit/grub.git/tree/include/grub/safemath.h#n29

@Suiseiseki @hfaust

> The only working way to detect integer overflow is to use a compiler built-in

On gcc, anyway.

@Suiseiseki @hfaust "open source" is the "latinx" of free software huh

@hakui @Suiseiseki @hfaust

> "open source" is the "latinx" of free software huh

It's more like "You're *Mexican*?"
youremexican.mp4

@p @hfaust Why would you use an inferior compiler?

@Suiseiseki @hfaust They used LLM to detecta bunch of very obvious on the nose buffer overflows (var + 1) to mitigate using (var + 1 < size).

Most of these can not exploited in practise and require physical access to the hardware.

Nobody cares and it’s a literal nothing burger and only displays that “AI” can do baby’s first C programming stuff.

You could’ve easily found these without Microsoft’s Copilot garbage if people actually cared about fixing obscure bugs that never are a problem are in practise.

@SuperDicq @hfaust >to mitigate using (var + 1 < size).
GCC's optimizer is so good it will detect that there's no way var + 1 will be smaller than var (signed integer overflow is undefined), therefore it optimizes out such check.

In the case where you have to add something to a variable from an input file that can be crafted by an attacker, you must use either use unsigned integers, or use __builtin_add_overflow() to avoid overflows.

@hfaust@shitposter.world RIP ReiserFS

@Suiseiseki @hfaust The funniest line in this article is the following:

Furthermore, GRUB2 is coded in C, which is considered a memory-unsafe language, and as mentioned, does not benefit from any modern security mitigation.

I wonder which language Windows is mostly written with

@hfaust Note how they fail to mention that "Secure Boot" and UEFI has made security much worse than BIOS, as it allows crafting a single bootkit in an image file that will work across architectures, as well everyone uses the same UEFI implementation with the same vulnerable jpeg library (while an attacker had to craft an attack per BIOS implementation at least).

@SuperDicq @hfaust Windows is mostly written in C++ (which explains why it's so garbage), with some C and some C#.

Now they've started to write things in Rust.

@Suiseiseki @hfaust Doesn’t C++ have the same memory-safety “issues” that C has?

I assume Microsoft’s bootloader and bitloader and such is written in C/C++ and not Rust.

@SuperDicq @Suiseiseki @hfaust not necessarily, but i'd guess they don't exclusively use reference counting smart pointers

@Suiseiseki @hfaust

>

@begsby @Suiseiseki @hfaust @hakui Well, the joke is, like, people just assuming everyone is Mexican.

@begsby @p @Suiseiseki @hfaust but spain is just portugal

@Suiseiseki @hfaust true
But to be fair, there were only about two vendors for bios implementation at the end.

@nachtrabe @hfaust Sure, but every motherboard manufacturer made quite a few changes to make their own custom versions, meaning a generic rootkit wasn't really possible.

@hfaust

Security nuts do not understand that when you run free software only, "memory safety" is an afterthought, most of us would rather stick with a truly free, matured, reliable and performant software written in C than adopt proprietary, slow and unreliable Rust codebase.

@p @hfaust A proprietary compiler that is much worse functionally in every way is worse, not better.

@SuperDicq @hfaust If you use it wrong, C++ is worse than C when it comes to "memory-safety", as it has many more bloated features.

"C/C++" isn't a thing - both are different languages.

I believe m$'s bootloader is partly C and mostly C++.

@Suiseiseki @hfaust

> proprietary compiler

...GPLv3 is not proprietary. Ken's compiler is pure.

> worse functionally in every way

It's a nice compiler, it's comfortable, and it's a tool instead of some product of a committee of UB-Nazis trying to shove their opinion into your program. It is also fast, it produces good machine code, and cross-compilation is *trivial*.

>
new_c_compiler.pdf

@p @Suiseiseki @hfaust
Plan 9:
>compile quickly, load slowly, and produce medium quality object code.

gcc:
>produce bad machine code until Apple pours millions into you
>fragile codebase, a lot of tech debt
>cross-compiling can be a pain depending on how esoteric your target is (literally anything that isn't a Linux host)

@phnt @Suiseiseki @hfaust

> (literally anything that isn't a Linux host)

And God help you if you want to statically link the program.

@p @Suiseiseki @hfaust Hey, I saw you passed --disable-shared to the autotools script. Therefore I'll dynamically link against the libc on your system, or if you are crosscompiling I'll link to the sysroot libc with headers I broke during the fix-includes target.

@eliseo01 That's why I don't trust when people push for a Rust rewrite, every time they do, you find a piece of software licensed in MIT just they will be able to close it later.

@p @hakui @Suiseiseki @hfaust I'm technically not but yesterday I ate a burrito so that's fixed. I'm mexican now.

@hfaust i mean, they're not wrong

@hfaust@shitposter.world last I remember it also used Ruby

@yakumo_izuru

@hfaust

Rust itself is arguably proprietary already due to the compiler and the usual corporate trademark shenanigans.

@kerosene @Suiseiseki @hakui @hfaust Gotta get some more burritos, honkeytown doesn't have any options.
pmexican.jpg