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

111–120 of 190 posts

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

#111

Post by metaltyphoon »

mshroyer wrote: post #59
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…

He's been especially arrogant and dismissive on X. I'm very glad Fil-C exists, but his behavior makes me doubt the whole project.

Mark? AwareDigital 2013?

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

#112

Post by quotemstr »

pizlonator wrote: post #110
quotemstr wrote: post #106

Earlier quoted context omitted.

> In a race, you at worst access an object you could have loaded from whatever field you were racing on. Suppose a pointer ptr is initialized to foo and transitions once to bar; suppose also that x is attacker-controlled. Then, T1: T* p = ptr; if (p == bar) p[x] = 7 T2: ptr = bar A program can observe p == bar (testing the address bits) but still permit a write to foo through p (allowed by the stale capability bits a…

The “bug” in your example hinges on this: > if (p == bar) It is not in scope of memory safety to make sure that logic not related to memory accesses works as you expected. In Fil-C, the integer pointer value (the intval) is not trusted. You could get it wrong with things more sexy than races (integer overflows or just plain bad math). Fil-C just guarantees that your accesses obey the capability model, which is true i…

> It is not in scope of memory safety to make sure that logic not related to memory accesses works as you expected

This logic is related to memory accesses. This is not an issue that can occur in systems that provide the memory-safety guarantees that the words "memory safe" usually name.

You can't escape failure to meet a public definition of a term by adopting a private definition. The English language has a term for this pattern.

> You’re being disingenuously imprecise

You are the one being imprecise. You claim that because T1 could access foo at some time in the past, it's okay for a subsequent execution to access foo when the program text limits the access to bar. The temporal history is irrelevant. You are taking language that applies to inter-actor access control and applying it to invalid execution detection.

If T1 and T2 were, say, mutually untrusting actors over a network, that T1 had a capability at one point would be a valid defense. We're talking about a totally different scenario, not an object-capability security system, but preventing attackers turning illegal C into various kinds of exploit, e.g. EOP, information disclosure, and so on.

It does not matter that T1 used to have the capability and could have used it. We're talking about an attacker using an exploit to make T1 do his bidding, not T1 itself being a hostile actor running in a sandbox.

You can't just define the problem away. Real-world C has these races. They've been exploitable. Your system doesn't close them.

> Hence, this isn’t an arbitrary memory access.

Not arbitrary, true. Irrelevant. It's a cross-object access that violates programmer expectations and is likely exploitable.

> This is a memory access that obeys the capability model

You're using the English words that denote a strong guarantee in the security community and using them to describe your weaker system.

> I think that is doing more damage than anything I have said

Damage to what? You can't fix this problem in Fil-C without introducing atomics to every globally-visible store path, so you're going around the internet trying to play definition games to define it out of existence. The only damage here is to people who think Fil-C provides stronger mitigations than it does.

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

#114

Post by anon-3988 »

AlotOfReading wrote: post #50
jagadaga wrote: post #32

Earlier quoted context omitted.

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

I don't understand why Result type is necessarily slower. Result that simply bubbles up is basically an exception, no?

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

#115

Post by uecker »

josephg wrote: post #76
flumpcakes wrote: post #64

Earlier quoted context omitted.

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.

I think Fil-C might make a lot of sense for running legacy C or C++ codebases. But for new code, it seems like it’s trying to compete with other GC languages. Take away C’s performance advantages and I don’t know why anyone would use it. Fil-C: Combining the ergonomics of C with the performance of Python!

I like using C. It is simple, elegant, has very fast compilation times, requires no FFI needed for many libraries, is extremely stable and extremely portable, a large ecosystem, and, most importantly, I do not think the ergonomics of C are bad.

It is inconvenient to start using it as it comes with basically nothing out of the box, but this is irrelevant after a short time using it.

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

#116

Post by AlotOfReading »

anon-3988 wrote: post #114
AlotOfReading wrote: post #50

Earlier quoted context omitted.

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.

I don't understand why Result type is necessarily slower. Result that simply bubbles up is basically an exception, no?

You need instructions to check the result type, and a bit somewhere to store whether it's valid. Most exceptions only add extra instructions during throws/unwinding. There may or may not be an overall reduction in code size, depending on how many checks you have vs table entries.

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

#118

Post by pjmlp »

josephg wrote: post #92
baranul wrote: post #87

Earlier quoted context omitted.

Of the group of languages presented, your argument has more merit for Go. With C# and others, there is an additional OOP argument in there, that splits into different factions. But what is being overlooked, is the massive numerical dominance of C programmers and projects, along with legacy and embedded code. There is going to be a preference for writing and using C, that could arguably fuel Fil-C for a very long time…

> But what is being overlooked, is the massive numerical dominance of C programmers I roll to doubt. I haven’t seen C topping programming language popularity charts for a long, long time. I used to interview software engineering candidates professionally. Candidates could pick any language they wanted for the interview. Python was chosen by about 70% of our interviewees. C was under 5%. (N=400 or so)

Speaking for myself, I am never hired because I know C or C++, rather specific managed languages, however if there is the need to look under the runtime hood, or have bindings, like most Python libraries actually are, then suddenly it is welcome that I know C and C++ versus most folks on the team.

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

#119

Post by uecker »

steveklabnik wrote: post #82
uecker wrote: post #78

Earlier quoted context omitted.

A: "Rust prefers to prevent all undefined behavior statically" me: It does dynamic bounds checking. Rustaceans: But... for XYZ ... it doesn't... Sigh.

It's because you're not using words in the way that people use them when talking about this stuff. Rust (outside of the unsafe superset) has no undefined behavior. That is guaranteed, statically, at compile time: all execution paths have well-defined behaviors. That does not mean that there are no runtime consequences whatsoever. For example, the behavior of an invalid index is a panic, at runtime. Inserting a check…

Rust does not do prevent all UB statically. Even if you guarantee at compile-time that all execution paths have well-defined semantics because compiler inserted run-time checks, this is not the same thing as "statically ensuring the absence of this run-time condition that would cause UB" which would be what people usually mean with "statically preventing UB". So I think it is not me who uses the works in an unusual way.

If, of course, you redefined words so that adding run-time checks counts as "statically preventing all UB", then this applies to Fil-C just as well! You can not have it both ways.

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

#120

Post by uecker »

wasmperson wrote: post #85
uecker wrote: post #68

Earlier quoted context omitted.

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]; }

Now it's your example that's too simple. I can't present a counter-example that wouldn't look totally different: if you avoid the indexing operator then trivially incorrect code like that becomes unrepresentable. It's like if I said destructors help you avoid memory leaks and you asked how you'd avoid a leak in a single-function program that does nothing but call `Box::leak()`. Again: I'm not disputing the fact that…

If you agree with that Rust sometimes has to add dynamic bounds check, then you could have just agreed with my original comment.
Post reply on HN