5 ms·

They made C memory safe? This is a big thing to gloss over in a single paragraph. Does anyone have extra details on this? > On devices with iOS 14 and iPadOS 1

They made C memory safe? This is a big thing to gloss over in a single paragraph. Does anyone have extra details on this? > On devices with iOS 14 and iPadOS 14 or later, Apple modified the C compiler toolchain used to build the iBoot bootloader to improve its security. The modified toolchain implements code designed to prevent memory- and type-safety issues that are typically encountered in C programs. For example, it helps prevent most vulnerabilities in the following classes: > • Buffer overflows, by ensuring that all pointers carry bounds information that’s verified when accessing memory > • Heap exploitation, by separating heap data from its metadata and accurately detecting error conditions such as double free errors > • Type confusion, by ensuring that all pointers carry runtime type information that’s verified during pointer cast operations > • Type confusion caused by use after free errors, by segregating all dynamic memory allocations by static type

vsgherzi 8mo ago
Sort of. From my understanding they’ve been heavily using clang with fbounds checks to insert checks into functions. I think there was work done to try to insert them into existing code as well. They memory tagging in new processors help avoid overflow exploitation. Maybe someone can jump in and add more details
bri3d 8mo ago
Many years ago. It’s called Firebloom. I think it’s similar in theory and lineage to Fil-C. https://saaramar.github.io/iBoot_firebloom/ https://saaramar.github.io/iBoot_firebloom/
1over137 8mo ago
>They made C memory safe? They made a dialect of C with bounds safety, see: https://clang.llvm.org/docs/BoundsSafety.html#overview https://clang.llvm.org/docs/BoundsSafety.html#overview
- deleted 8mo ago
  [deleted]
pjmlp 8mo ago
Yes, that is however a dialect, and one of the goals to Swift Embedded roadmap is to replace it.
- ksec 8mo ago
  So they were not joking when they say they want Swift to replace from Assembly to Javascript. I dont think this will end well.
  - pjmlp 8mo ago
    It has been on Swift and Apple's official documentation since the early days. People keep forgetting that Objective-C also had a full stack role on NeXTSTEP. And the same full stack approach was also a thing on Xerox PARC systems, which mostly failed due to mismanagement. Usually ends well for closed source platform vendors when developers aren't allowed to come up with alternatives like on FOSS operating systems. At least, as long as the platform stays market relevant.
    - ksec 8mo ago
      >People keep forgetting that Objective-C also had a full stack role on NeXTSTEP. In terms of Apps and Low Level Stack Objective-C doesn't seems wrong in my book. The problem is Swift begin as a much larger language and evolve into a gigantic pile of a little of everything.
      - pjmlp 8mo ago
        Doesn't seem to hinder C++, which modern C compilers are written with nowadays. Despite all its complexity, LLVM and GCC aren't getting rewritten any time soon, or the OSes that rather use C++ subsets instead of being stuck with C.
  - int_19h 8mo ago
    Why? There's no particular reason why a language can't span low-level to high-level. C# is a good example of that: normally you deal with garbage collected objects and references, but if you need to drop down to explicit stack allocations, raw pointers, unions etc, you can - though of course the resulting code looks very different from idiomatic high-level code.

vsgherzi 8mo ago

Sort of. From my understanding they’ve been heavily using clang with fbounds checks to insert checks into functions. I think there was work done to try to insert them into existing code as well. They memory tagging in new processors help avoid overflow exploitation. Maybe someone can jump in and add more details

bri3d 8mo ago

Many years ago. It’s called Firebloom. I think it’s similar in theory and lineage to Fil-C. https://saaramar.github.io/iBoot_firebloom/ https://saaramar.github.io/iBoot_firebloom/

1over137 8mo ago

>They made C memory safe? They made a dialect of C with bounds safety, see: https://clang.llvm.org/docs/BoundsSafety.html#overview https://clang.llvm.org/docs/BoundsSafety.html#overview

deleted 8mo ago
[deleted]

pjmlp 8mo ago

Yes, that is however a dialect, and one of the goals to Swift Embedded roadmap is to replace it.

ksec 8mo ago
So they were not joking when they say they want Swift to replace from Assembly to Javascript. I dont think this will end well.
- pjmlp 8mo ago
  It has been on Swift and Apple's official documentation since the early days. People keep forgetting that Objective-C also had a full stack role on NeXTSTEP. And the same full stack approach was also a thing on Xerox PARC systems, which mostly failed due to mismanagement. Usually ends well for closed source platform vendors when developers aren't allowed to come up with alternatives like on FOSS operating systems. At least, as long as the platform stays market relevant.
  - ksec 8mo ago
    >People keep forgetting that Objective-C also had a full stack role on NeXTSTEP. In terms of Apps and Low Level Stack Objective-C doesn't seems wrong in my book. The problem is Swift begin as a much larger language and evolve into a gigantic pile of a little of everything.
    - pjmlp 8mo ago
      Doesn't seem to hinder C++, which modern C compilers are written with nowadays. Despite all its complexity, LLVM and GCC aren't getting rewritten any time soon, or the OSes that rather use C++ subsets instead of being stuck with C.
- int_19h 8mo ago
  Why? There's no particular reason why a language can't span low-level to high-level. C# is a good example of that: normally you deal with garbage collected objects and references, but if you need to drop down to explicit stack allocations, raw pointers, unions etc, you can - though of course the resulting code looks very different from idiomatic high-level code.