Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fil-C: Garbage In, Memory Safety Out [video]

youtube.com

Post reply on HN
Print view View original

61–70 of 190 posts

Re: Fil-C: Garbage In, Memory Safety Out [video]

#61

Post by tialaramex »

Ha, looking through the links dang added, I came upon something I wrote back in December

I gave (somewhat arbitrarily) the example that safe Rust is OK with a 64-bit pointer (on a modern PC for example) having the value made by the UTF-8 text "LAUGHING". That's 8 bytes, 8 bytes is 64 bits, it fits perfectly. Of course I point out, unsafe Rust, which is allowed to dereference pointers, must never dereference this LAUGHING pointer, it's not actually pointing at anything, but it is allowed to exist in safe Rust.

Coincidentally, in like February or so this year, a new third-party Rust type "ColdString" was introduced to their reddit by somebody I've never met - I read about it and encouraged its author. ColdString is 64 bits (on modern hardware) because inside it's a pointer, and indeed if the text you wanted to store in a ColdString was "LAUGHING" you do that exactly as I described in the December post - it's just the UTF-8 encoded text, no problem. The clever trick inside ColdString is how it can know when that 64-bit pointer really is actually a pointer for longer strings - yet also allows any 0 to 8 byte UTF-8 text string to just be encoded in the ColdString itself directly.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#62

Post by NobodyNada »

dundarious wrote: post #34
quotemstr wrote: post #22

Earlier quoted context omitted.

Every one of these posts is the same. There's this weird blindness to the problems and imperfections in Fil-C --- just shouting down. It reduces my confidence in Fil-C as a whole. Rust, for all its faults, at least engages with its critics. I've long faulted Rust's use of Result over exceptions, for example, but the maintainers at least acknowledge that other options exist and each has trade-offs. Not Pizlo and his f…

> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks) If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere. Safety is always conditional on the underlying unsafe implementation having no bugs.

With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies.

So either way you're in the same situation of relying on the correctness of the unsafe code you depend on. But there are two major differences:

- Unsafe code can be written in Rust, instead of inside the compiler. This is much easier to write and to review for correctness.

- People other than Fil are allowed to write unsafe Rust. This is what Fil's point is about, and yes, it allows you to opt-in to increasing your attack surface by trusting unsafe code written by yourself or your dependents. Rust allows the user to choose where they draw the trust boundary, and Fil-C does not.

It's true that Fil is probably better than I am at writing unsafe code. So "Fil-C is safer than Rust" is true in that sense. But Fil-C is certainly not safer than safe Rust. And sure, you can't run all the Rust code in the world if you compile with '--deny unsafe_code'; but Fil-C can't run all the C code in the world either. Unsafe Rust is rarely needed, mostly only if you want to do pointer crimes or FFI, and Fil-C doesn't support a lot of (perfectly legal) pointer crimes and FFI either.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#63

Post by Cyph0n »

modeless wrote: post #58
Cyph0n wrote: post #56

Earlier quoted context omitted.

But the runtime cost of Fil-C means that - in most cases - your actual production application will be compiled with a standard C compiler. This applies not just to your code, but to all dependencies (due to ABI). So I don’t see how Rust is at a huge disadvantage here when Fil-C is typically not going to be enforcing safety in production. I suppose the testing/fuzzing story becomes all the more important because you n…

The whole point of Fil-C is that it is fast enough to consider using in production for some applications while still guaranteeing memory safety. We already have ASAN and Valgrind and other tools for development purposes, that's not what Fil-C is targeting.

I am assuming that Fil-C introduces orders of magnitude less overhead than ASAN or Valgrind.

Also, it’s probably fast enough for apps to be deployed in something like a staging environment for integration tests to run against them. Production deploy/release can then happen using a tagged version that gets compiled using vanilla GCC/Clang.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#64

Post by flumpcakes »

wasmperson wrote: post #60
pizlonator wrote: post #43

Earlier quoted context omitted.

Custom libc does not call to system libc. “Custom” and “system” aren’t the terms I use; I say user libc and you libc (because they are basically the same libc - either both are musl or both are glibc). User libc calls to the Fil-C runtime, which filters syscalls, and those filtered syscalls are made via yolo libc. Hence, a Fil-C program is memory safe down to the syscalls and syscalls cannot be used to escape the pro…

The way I see it, as far as memory safety is concerned that's just framing. Both Fil-C and Rust have a boundary below which the unsafe lives. If Fil-C is only safer than rust when you don't pass the `-F unsafe_code` argument to rustc then IMO "safer" in this case is somewhat of an empty claim.

I think you should watch the linked presentation, it will show how it is "safer" than rust. Unfortunately there are performance implications, but fil-c seems fast enough to go into production for many workloads and surprisingly needs very little code changes to existing C/C++ projects which is a huge benefit.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#65

Post by modeless »

Cyph0n wrote: post #63
modeless wrote: post #58

Earlier quoted context omitted.

The whole point of Fil-C is that it is fast enough to consider using in production for some applications while still guaranteeing memory safety. We already have ASAN and Valgrind and other tools for development purposes, that's not what Fil-C is targeting.

I am assuming that Fil-C introduces orders of magnitude less overhead than ASAN or Valgrind. Also, it’s probably fast enough for apps to be deployed in something like a staging environment for integration tests to run against them. Production deploy/release can then happen using a tagged version that gets compiled using vanilla GCC/Clang.

I'm not sure about the speed of ASAN, it may be comparable but doesn't guarantee memory safety. It's only for catching mistakes and not secure against an adversary. Valgrind is dramatically slower.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#66

Post by flumpcakes »

NobodyNada wrote: post #62
dundarious wrote: post #34

Earlier quoted context omitted.

> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks) If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

Machine code is unsafe, so any memory-safe language must necessarily be built on some unsafe code somewhere . Safety is always conditional on the underlying unsafe implementation having no bugs. With Fil-C, the "unsafe blocks" live entirely within the compiler and runtime. With Rust, the unsafe foundation is the Rust compiler and standard library, as well as any unsafe code within your application or dependencies. So…

There are no 'unsafe' blocks in Fil-C. I think you trying to conflate 'unsafe blocks' with the fact that there might be compiler errors which might break 'safety'? Which is equally true in any system including Rust.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#67

Post by modeless »

pizlonator wrote: post #44
modeless wrote: post #38

Earlier quoted context omitted.

Better include Rowhammer too. Maybe Fil-C should run a test and refuse to start on any system with bad RAM or unpatched CPU errata. It could also monitor the voltage to protect against undervolting attacks. And you'll need some cosmic ray shielding too. Of course I'm kidding, but it is absolutely the case that if you truly care about safety you need to consider more than the program source code and binary, but also t…

Sure all of those are escape hatches that work against any memory safety tech. Point is, Fil-C goes further than any other memory safety tech in terms of what it guards

Fully agreed. At some point you have to draw a line and say that the rest is the responsibility of the kernel and hardware and user, and I think Fil-C drew that line in the right place.

Re: Fil-C: Garbage In, Memory Safety Out [video]

#68

Post by uecker »

wasmperson wrote: post #54
uecker wrote: post #35

Earlier quoted context omitted.

These are not terribly interesting cases though, as it would also be impossible to get an oob access in other languages either.

Yes, rust didn't invent the concept of an iterator, and is thus not the only language which offers a solution to statically avoid bounds checks. Feel free to give a more "interesting" case you believe rust wouldn't be able to handle.

Rust fails to prove basic indirection to be statically safe and instead does a run-time check.

  fn main() {
    let v = vec![1, 2, 3];
    v[5];
  }

Re: Fil-C: Garbage In, Memory Safety Out [video]

#69

Post by [deleted] »

dundarious wrote: post #34
quotemstr wrote: post #22

Earlier quoted context omitted.

Every one of these posts is the same. There's this weird blindness to the problems and imperfections in Fil-C --- just shouting down. It reduces my confidence in Fil-C as a whole. Rust, for all its faults, at least engages with its critics. I've long faulted Rust's use of Result over exceptions, for example, but the maintainers at least acknowledge that other options exist and each has trade-offs. Not Pizlo and his f…

> claim that other systems are worse in ways they are not (e.g. with respect to Rust having unsafe blocks) If considering only "safety", then Fil-C is more safe than any Rust containing unsafe blocks, no? With the usual caveats about whether an abort() is safe.

[deleted]

Re: Fil-C: Garbage In, Memory Safety Out [video]

#70

Post by wildfireday2 »

modeless wrote: post #40
Cyph0n wrote: post #39

Earlier quoted context omitted.

How is Fil-C’s wrapper approach different from someone (not necessarily the Rust stdlib) implementing a safe wrapper around a particular syscall? mmap is a bit of an outlier because it is not possible to implement a fully featured safe wrapper (MAP_SHARED) in Rust. So I would be curious to see what safety guarantees Fil-C claims to provide for mmap.

Adding Fil-C-like runtime checks to Rust is definitely an interesting direction. As I mentioned upthread. It's not just the availability of the safe API that's interesting, though, but also the prohibition on using the unsafe API in the entire program and all dependencies. Which Rust could also do in theory but not yet in practice AFAIK.

Complete memory safety (much less concurrent garbage collection) isn’t really workable for things like kernel and some embedded programming contexts. Rust can work in those contexts precisely because it has an unsafe out.

Even so Fil-C fails at being 100% compatible for userspace due to the silly things people do with pointers. Hence the large amount of effort he’s had to do to fix up that 0.1% of userspace that breaks.

Post reply on HN