6 ms·

I think that ownership for C is gross. It's hard to convert code to something like this. But you could get most of the benefit by just isoheaping (strictly all

I think that ownership for C is gross. It's hard to convert code to something like this. But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps).

pjc50 3y ago
> I think that ownership for C is gross CVEs are gross. How do you prove your code is free from use-after-free and so on?
- pizlonator 3y ago
  Don't have to if I use isoheaps.
  - pjc50 3y ago
    You can still use-after-free in an isoheap, you're just reusing a freed object of the same type.
DriftRegion 3y ago
Say more about isoheaping and how it helps? Is this related to arena allocation? A quick search doesn't find anything on this. Thanks.
- pizlonator 3y ago
  One heap per type. Here’s an allocator optimized for that use case. https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/libpas/Documentation.md https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...
  - thradams 3y ago
    The ownership works for non pointers. We can have integers (handles) that are owners. This allow custom allocators for instance. The concept of owner is some value that works as reference to an object and manages its lifetime.
saagarjha 3y ago
This doesn’t help for a lot of things, including some of the examples described in the article. For example trying to segregate file descriptors (or similar resource handles) to an isolated heap would be mostly worthless because a UAF through a “stale reference” would let you mess with a completely different file. In general the problem of figuring out which objects are safe to confuse with each other is very difficult. There are a handful of “obvious” types (collections, ports, etc.) that it’s clear cannot be allocated together because they hold capabilities but doing this in general is not tractable.
- pizlonator 3y ago
  Sure ownership protects against more things. But some coding patterns are impossible under it.
  - thradams 3y ago
    The analysis can be disabled or silenced in some functions. the "static state" also can be override. (see the realloc sample) Because this is C, the programmers can do wherever they want, but before it must do some negotiation with the static analysis.
    - pizlonator 3y ago
      I’d rather just have memory safety. If all you give me is half measures, then I’ll either just use plain old C/C++ or I’ll switch to a totally different language. Maybe one with a GC so I don’t have to please some ownership thingy.
      - thradams 3y ago
        Everything related to safety is on my list. (the list is big) I think big problems can be broken down into smaller ones.
        pizlonator 3y ago
thradams 3y ago
Converting code can be challenging. The cake code has been successfully converted. null-checks are not ready, and something similar already happened to c#. The experience is similar to changing a header file to use a const argument where previously the argument was non-const. This change will propagate everywhere. I also think a similar experience is converting JavaScript to typescript. The type system will complain before it stabilizes.
- pizlonator 3y ago
  Have you made OpenSSL, or something big like that, completely memory safe this way? As in, running nothing but memory-safety-ified C code down to the syscall boundary?
  - thradams 3y ago
    The ownership checks are new in Cake, less than one year. So the answer is no, just cake is using. And there is a lot of work to do..in flow analysis etc. The cake source itself is moving to another experimental feature that is nullable types. Similar of C# https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref...
matheusmoreira 3y ago
> But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps). Can you elaborate on this? I've been reading up on memory allocation algorithms and most of them seem to favor segregation of blocks by element size instead. Are there additional benefits to coming up with a complex typing scheme for a custom memory allocation interface?
- pizlonator 3y ago
  No benefits other than safety.

pjc50 3y ago

> I think that ownership for C is gross CVEs are gross. How do you prove your code is free from use-after-free and so on?

pizlonator 3y ago
Don't have to if I use isoheaps.
- pjc50 3y ago
  You can still use-after-free in an isoheap, you're just reusing a freed object of the same type.

DriftRegion 3y ago

Say more about isoheaping and how it helps? Is this related to arena allocation? A quick search doesn't find anything on this. Thanks.

pizlonator 3y ago
One heap per type. Here’s an allocator optimized for that use case. https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/libpas/Documentation.md https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...
- thradams 3y ago
  The ownership works for non pointers. We can have integers (handles) that are owners. This allow custom allocators for instance. The concept of owner is some value that works as reference to an object and manages its lifetime.

saagarjha 3y ago

This doesn’t help for a lot of things, including some of the examples described in the article. For example trying to segregate file descriptors (or similar resource handles) to an isolated heap would be mostly worthless because a UAF through a “stale reference” would let you mess with a completely different file. In general the problem of figuring out which objects are safe to confuse with each other is very difficult. There are a handful of “obvious” types (collections, ports, etc.) that it’s clear cannot be allocated together because they hold capabilities but doing this in general is not tractable.

pizlonator 3y ago
Sure ownership protects against more things. But some coding patterns are impossible under it.
- thradams 3y ago
  The analysis can be disabled or silenced in some functions. the "static state" also can be override. (see the realloc sample) Because this is C, the programmers can do wherever they want, but before it must do some negotiation with the static analysis.
  - pizlonator 3y ago
    I’d rather just have memory safety. If all you give me is half measures, then I’ll either just use plain old C/C++ or I’ll switch to a totally different language. Maybe one with a GC so I don’t have to please some ownership thingy.
    - thradams 3y ago
      Everything related to safety is on my list. (the list is big) I think big problems can be broken down into smaller ones.
      - pizlonator 3y ago

thradams 3y ago

Converting code can be challenging. The cake code has been successfully converted. null-checks are not ready, and something similar already happened to c#. The experience is similar to changing a header file to use a const argument where previously the argument was non-const. This change will propagate everywhere. I also think a similar experience is converting JavaScript to typescript. The type system will complain before it stabilizes.

pizlonator 3y ago
Have you made OpenSSL, or something big like that, completely memory safe this way? As in, running nothing but memory-safety-ified C code down to the syscall boundary?
- thradams 3y ago
  The ownership checks are new in Cake, less than one year. So the answer is no, just cake is using. And there is a lot of work to do..in flow analysis etc. The cake source itself is moving to another experimental feature that is nullable types. Similar of C# https://learn.microsoft.com/en-us/dotnet/csharp/nullable-references https://learn.microsoft.com/en-us/dotnet/csharp/nullable-ref...

matheusmoreira 3y ago

> But you could get most of the benefit by just isoheaping (strictly allocate different types in different heaps). Can you elaborate on this? I've been reading up on memory allocation algorithms and most of them seem to favor segregation of blocks by element size instead. Are there additional benefits to coming up with a complex typing scheme for a custom memory allocation interface?

pizlonator 3y ago
No benefits other than safety.