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

31–40 of 190 posts

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

#31

Post by jcranmer »

quotemstr wrote: post #21
modeless wrote: post #10

Earlier quoted context omitted.

Rust doesn't runtime validate that your usage of syscalls is memory safe, while Fil-C does. For example you can call mmap in Fil-C and it is still guaranteed to be memory safe, while in Rust you can easily violate memory safety by calling mmap. This seems like an unambiguous improvement to me. This is as memory safe as it is possible to be on a system with a kernel that is not memory safe. Adding Fil-C-like runtime c…

Okay, let me know when I can call process_vm_writev or ptrace and have Fil-C verify safety properties on the result.

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

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

#32

Post by jagadaga »

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…

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

Why?

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

#33

Post by doctorpangloss »

cypherpunk666 wrote: post #3
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…

indeed, the ideas could be used more widely. fil-c runs on linux. what if linux ran on fil-c?

what if fil-c could draw pelicans?

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

#34

Post by dundarious »

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…

> 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.

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

#35

Post by uecker »

wasmperson wrote: post #29
uecker wrote: post #9

Earlier quoted context omitted.

Arguably the most important memory safety property, i.e. bounds checking for dynamic arrays, is also not statically checked in Rust.

This isn't entirely true. Rust's indexing operator performs a dynamic check but the language and stdlib have a number of ways to access array elements without indexing, which is effectively a form of static checking. For example, the following loop is statically guaranteed to not go OOB, and will not emit any unnecessary bounds checks: for i in some_arr { println!("{i}"); } I suspect most techniques you could think o…

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

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

#36

Post by uecker »

woodruffw wrote: post #16
uecker wrote: post #9

Earlier quoted context omitted.

Arguably the most important memory safety property, i.e. bounds checking for dynamic arrays, is also not statically checked in Rust.

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.

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

#37

Post by uecker »

LoganDark wrote: post #17
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.)

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.

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

#38

Post by modeless »

jcranmer wrote: post #31
quotemstr wrote: post #21

Earlier quoted context omitted.

Okay, let me know when I can call process_vm_writev or ptrace and have Fil-C verify safety properties on the result.

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 the environment, including kernel and hardware. The user doesn't care if their web browser got hacked via stack buffer underflow or /dev/exynos-mem or Rowhammer; the result is the same.

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

#39

Post by Cyph0n »

modeless wrote: post #28
wasmperson wrote: post #26

Earlier quoted context omitted.

> For example you can call mmap in Fil-C and it is still guaranteed to be memory safe, while in Rust you can easily violate memory safety by calling mmap. That's the thing, though. Your Fil-C code isn't calling mmap, it's calling the Fil-C wrapper for mmap. In neither Fil-C nor Rust('s safe subset) can you call the actual system mmap.

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.

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

#40

Post by modeless »

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.

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.
Post reply on HN