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

41–50 of 190 posts

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

#41

Post by LoganDark »

uecker wrote: post #37
LoganDark wrote: post #17

Earlier quoted context omitted.

Presumably, they're talking about the possibility of explicitly replacing dynamic bounds checks in cases where it's statically provable that the access will not overrun. That doesn't necessarily mean you lose cases where you genuinely can't prove such a thing, but rather that it would be possible to opt into compiler assistance with proving it, rather than hoping LLVM will have your back. At least, that's how I'd env…

I merely pointed out that the statement "Rust prefers to prevent all undefined behavior statically" is misleading in the sense that Rust does not do this for all undefined behavior.

Maybe if you think of [] as offsetting a pointer rather than calling into an Index (or IndexMut) implementation. Since the return type isn't optional, a panic is the only way to avoid performing an invalid access or manufacturing an unfaithful return value. There are also optional accessors which do not panic, and unsafe/unchecked accessors.

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

#42

Post by woodruffw »

uecker wrote: post #36
woodruffw wrote: post #16

Earlier quoted context omitted.

How would Rust perform static checks on dynamic bounds? That seems like an impossible order, i.e. not a reasonable evaluation criteria for any (general-purpose) language. (I'm separately skeptical that it's the most important memory safety property; I suspect that a review of Chrome and Firefox 0days would show that UAFs and type confusion are, at least to attackers, equally if not more important.)

Rust can not do this. But the original claim is that it is all statically checked in Rust, and this is an obvious counter example. Some dependently types languages can prove this statically, also model checking can do this, etc. So it can be done statically as well, but not in Rust.

> But the original claim is that it is all statically checked in Rust

Where? The GP's comment says "prefers," which I didn't read to mean a blanket statement. I don't think anybody with more than passing experience in Rust (or C) would make such a claim.

> Some dependently types languages can prove this statically, also model checking can do this, etc. So it can be done statically as well, but not in Rust.

You're couching the part where it can't be done with full generality or can be done with full generality, but with punishing semantics. The appropriate comparison here is with other normal general purpose compiled languages.

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

#43

Post by pizlonator »

wasmperson wrote: post #2

He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too. Someone i…

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 protections (unless you do weird stuff with /proc)

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

#44

Post by pizlonator »

modeless wrote: post #38
jcranmer wrote: post #31

Earlier quoted context omitted.

Don't forget reads and writes of /proc/self/mem! :-)

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

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

#45

Post by pizlonator »

quotemstr wrote: post #8
wasmperson wrote: post #2

He claims that all syscalls are safe because they're implemented by his custom libc, but that libc then calls out to the system libc, where the system calls are unsafe. He then claims that this is unlike rust, where making a syscall is unsafe. If you stick to the rust standard library in the same way that fil-c programs stick to the fil-c standard library, then all of your rust "system calls" are safe, too. Someone i…

Both Rust and Fil-C have unsafe blocks, but in Fil-C latter system, only Pizlo gets to write them. Why am I not filled with confidence?

Fil-C has no unsafe blocks

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

#46

Post by uecker »

woodruffw wrote: post #42
uecker wrote: post #36

Earlier quoted context omitted.

Rust can not do this. But the original claim is that it is all statically checked in Rust, and this is an obvious counter example. Some dependently types languages can prove this statically, also model checking can do this, etc. So it can be done statically as well, but not in Rust.

> But the original claim is that it is all statically checked in Rust Where? The GP's comment says "prefers," which I didn't read to mean a blanket statement. I don't think anybody with more than passing experience in Rust (or C) would make such a claim. > Some dependently types languages can prove this statically, also model checking can do this, etc. So it can be done statically as well, but not in Rust. You're cou…

I read "Rust prefers to prevent all undefined behavior statically," to also imply that it actually does this, because otherwise the word "all" would not make sense to me in this sentence.

Dependently types languages and model checking do exist. They come with tradeoffs, but this is also true for Rust.

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

#47

Post by pizlonator »

quotemstr wrote: post #22
LugosFergus wrote: post #12

I was just thinking that we were overdue for a Fil-C post on HN.

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…

If you think you like Fil-C but aren’t able to see the specific way in which it’s better than Rust (more comprehensive safety), then what is it that you’re liking?

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

#48

Post by jitl »

Cyph0n wrote: post #39
modeless wrote: post #28

Earlier quoted context omitted.

Fil-C has access to a memory safe API called mmap with a lot of the capabilities of the mmap system call, while Rust's safe subset does not. Rust allows you to use the mmap system call unsafely, while Fil-C does not. I feel these are both big advantages for Fil-C. You'll never have to audit a Fil-C codebase to determine whether its calls to mmap are memory safe, or indeed any other calls to any API or dependency, eve…

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.

Rust is less safe because it has a feature for turning off safety, called `unsafe`. Fil-C does not have a way to turn off safety, and it enforces safety checks at runtime. That's the reasoning anyways. If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.

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

#49

Post by ratmice »

LoganDark wrote: post #24
ratmice wrote: post #23

Earlier quoted context omitted.

those are not dynamic bounds.

All "dynamic" means is that you don't know or don't prove the precise value statically. However you may know the range of possible values, or you may know properties of your algorithm that mean it can never attempt an out-of-bounds access. Sometimes you don't know any of these things, but sometimes you do.

What I was (badly) trying to express was more that given static bounds rust could also eliminate dynamic checks. So saying e.g. ATS can eliminate static checks, is kind of switching the target.

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

#50

Post by AlotOfReading »

jagadaga wrote: post #32
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…

>I've long faulted Rust's use of Result over exceptions Why?

Not the person you're asking, but result types pessimize code more, add register pressure, use more icache for largely dead code, etc. They're arguably noisier at the source level too.

That said, I've spent too much of my life chasing implicit control flow to accept exceptions. Heck, C++'s "noexcept" is a strong argument against exceptions all by itself.

Post reply on HN