3 ms·

It’s just probabilistic memory safety, at best Still cool, but not a replacement for memory safety language implementations.

OneDeuxTriSeiGo 1y ago
Memory coloring (what is to my knowledge being proposed) is certainly probabilistic however it really does a lot towards memory hardening more than memory safety. It makes successfully pulling off ROPs, etc far harder. Even if you are using a memory safe language, memory bugs still pop up in various places (cough FFI & ABI cough) so this is a massive step in the right direction towards blocking attacks even when the developers have done "all the right things" short of formally verifying their stack from top to bottom (and even then).
levodelellis 1y ago
I've been meaning to ask you what the motivation of your project is? Why would you want a safe-c? When I saw the headline I was worried that all my runtime code would break (or get slower) because I do some very unsafe things (I have a runtime that I compile with -nostdlib) I'm also tempted to write a commercial C++ compiler, but it feels like a big ask, paying for a compiler sounds ridiculous even if it reduces your compile time by 50x
- pizlonator 1y ago
  My motivation is that I love to write compilers
  - levodelellis 1y ago
    That's the best answer. Just wondering because you have a lot of experience and many people disagree with me. How realistic is a C++ compiler that's 50x faster than clang for debug builds? Assuming 1) there's enough work for each core 2) there's so many files/headers that a unity build takes 1/4th of the time as a rebuild using individual files (this theoretical compiler would be multi-threaded)
SchemaLoad 1y ago
MTE is as much a detection tool as it is a relied on layer of defence. I read that it has a 15 out of 16 chance to catch an error. Which means even if you do find a bug, it's going to be logged back to the OS vendor essentially the first time you use it. Getting patched permanently in the source.
- pizlonator 1y ago
  Any real world software has crashes that don’t get fixed. So you’d really have to use the attack a lot for it to get patched.

OneDeuxTriSeiGo 1y ago

Memory coloring (what is to my knowledge being proposed) is certainly probabilistic however it really does a lot towards memory hardening more than memory safety. It makes successfully pulling off ROPs, etc far harder. Even if you are using a memory safe language, memory bugs still pop up in various places (cough FFI & ABI cough) so this is a massive step in the right direction towards blocking attacks even when the developers have done "all the right things" short of formally verifying their stack from top to bottom (and even then).

levodelellis 1y ago

I've been meaning to ask you what the motivation of your project is? Why would you want a safe-c? When I saw the headline I was worried that all my runtime code would break (or get slower) because I do some very unsafe things (I have a runtime that I compile with -nostdlib) I'm also tempted to write a commercial C++ compiler, but it feels like a big ask, paying for a compiler sounds ridiculous even if it reduces your compile time by 50x

pizlonator 1y ago
My motivation is that I love to write compilers
- levodelellis 1y ago
  That's the best answer. Just wondering because you have a lot of experience and many people disagree with me. How realistic is a C++ compiler that's 50x faster than clang for debug builds? Assuming 1) there's enough work for each core 2) there's so many files/headers that a unity build takes 1/4th of the time as a rebuild using individual files (this theoretical compiler would be multi-threaded)

SchemaLoad 1y ago

MTE is as much a detection tool as it is a relied on layer of defence. I read that it has a 15 out of 16 chance to catch an error. Which means even if you do find a bug, it's going to be logged back to the OS vendor essentially the first time you use it. Getting patched permanently in the source.

pizlonator 1y ago
Any real world software has crashes that don’t get fixed. So you’d really have to use the attack a lot for it to get patched.