11 ms·
I like to share this every time there's a post about memory safe C: Apple has a memory-safer C compiler/variant they use to compile their boot loaders: https:
by nielsbot 1y ago
I like to share this every time there's a post about memory safe C:
Apple has a memory-safer C compiler/variant they use to compile their boot loaders:
https://saaramar.github.io/iBoot_firebloom/ https://saaramar.github.io/iBoot_firebloom/
- astrange 1y agoA descendent of this is in clang as -fbounds-safety.
- pjmlp 1y agoThat is basically clang getting something like MSVC SAL, the more the merrier.
- kragen 1y agoYeah, fat pointers are definitely a viable approach, but a lot of the existing C code that is the main argument for Fil-C assumes it can put a pointer in a long. (Most of the C code that assumed you could put it in an int has been flushed out by now, but that was a big problem when the Alpha came out.) I'm guessing that the amount of existing C code in Apple's bootloader is minimal, maybe 1000 lines, not the billions of lines you can compile with Fil-C.
- 1718627440 1y agoWhy not assume it fits into an uintptr_t, which is the type for exactly this purpose?
- matthewfcarlson 1y agoYou’re off by a few orders of magnitude. I’ll grant you, what is the bootloader becomes a very complex question. Even if you scope it to just “what is the code physically etched into the chip as the mask ROM” (secureROM) you’re talking hundreds of thousands. If you’re talking about all the code that runs before the kernel starts executing you’re talking hundreds of millions.
- kragen 1y agoNo, I was only talking about the pre-existing C code that wasn't written for the bootloader, which therefore might have incompatibilities with fat pointers you had to hunt down and fix. Also I'm really skeptical about your "hundreds of millions" number, even if we're talking about all the code that runs before the kernel starts. How do you figure? The entire Linux kernel doesn't contain a hundred millions of lines of code, and that includes all the drivers for network cards, SCSI controllers, and multiport serial boards that nobody's made in 30 years, plus ports to Alpha, HP PA-RISC, Loongson, Motorola 68000, and another half-dozen architectures. All of that contains maybe 30 million lines. glibc is half a million. Firefox 140.4.0esr is 33 million. You're saying that the bootloader is six times the size of Firefox? Are you really suggesting that tens of gigabytes of source code are compiled into the bootloader? That would make the bootloader at least a few hundred megabytes of executable code, probably gigabytes, wouldn't it?
- jacquesm 1y ago100's millions is clearly nonsense, but Grub2, which arguably is a (second stage) bootloader is half a million lines. It's interesting that this is a bootloader, and not an operating system in its own right, and a nice example of software bloat.
- ummonk 1y agoCouldn’t one just make long bigger then to make it match?
- kragen 1y agoMaybe so; I haven't tried. Probably a lot less code depends on unsigned long wrapping at 2⁶⁴ than used to depend on unsigned int wrapping at 2¹⁶, and we got past that. But stability standards were lower then. Any code that runs on both 32-bit and 64-bit LP64 systems can't be too dependent on the exact sizeof long, and sizeof long already isn't sizeof int the way it was on 32-bit platforms.
- ummonk 1y agoI'd actually keep it still wrapping at 2^64, with the extra metadata not participating in arithmetic operations...
- cryptonector 1y agoIt's going to break stuff one way or another.
- jibal 1y agoThere's a lot of code that makes assumptions about the number of bytes in a long rather than diligently using sizeof ... remember, the whole point here is low quality code.
- kbolino 1y agoThat seems worse. For all the wrong code that assumes long can store a pointer, there's likely a lot more wrong code that assumes long can fit in 64 bits, especially when serializing it for I/O and other-language interop. Also, 128-bit integers can't fit in standard registers on most architectures, and don't have the full suite of ALU operations either. So you're looking at some serious code bloat and slowdowns for code using longs. You've also now got no "standard" C type (char, short, int, long, long long) which is the "native" size of the architecture. You could widen int too, but a lot of code also assumes an int can fit in 32 bits.
- conradev 1y agoand the author of Fil-C worked on that!
- kragen 1y agoOh, somehow I missed that connection!
- pizlonator 1y agoThat was my idea and I wrote a good chunk of the compiler and runtime.
- kragen 1y ago(For those who didn't make the connection, pizlonator also wrote Fil-C.)
- frumplestlatz 1y ago[flagged]
- pizlonator 1y agoSounds like you weren't there
- frumplestlatz 1y ago[flagged]
- actionfromafar 1y agoYou don't want to - so you did it anyway?
- geocar 1y ago
- EPWN3D 1y agoYou don't even need to reverse it. It's in the public clang, and I'm working on helping my team adopt it in some test cases. And it's not just the bounds-checking that's great -- it makes a bunch of C anti-patterns much harder, and it makes you think a lot harder about pointer ownership and usage. Really a great addition to the language, and it's source-compatible with empty macro-definitions (with two exceptions).
- kragen 1y agoInteresting! How do you get started?
- EPWN3D 1y ago-fbounds-safety is the flag. https://clang.llvm.org/docs/BoundsSafety.html https://clang.llvm.org/docs/BoundsSafety.html
- pizlonator 1y ago> It's in the public clang I think you’re thinking of something else
- debugnik 1y agoIt or something similar has apparently been upstreamed to clang as -fbounds-safety. I don't know if they're the same, but the RFC on -fbounds-safety does give some credit to the author of Fil-C, who also took credit for firebloom on this thread as well.
- pizlonator 1y agoNot the same
- debugnik 1y agoThanks for clarifying, I had found a past HN comment stating they are the same.
- pjmlp 1y agoNot for much longer, replacing it with Swift is one of the reasons why Swift Embedded subset came to be. "Why Embedded Swift" https://youtu.be/LqxbsADqDI4?t=144 https://youtu.be/LqxbsADqDI4?t=144