111–120 of 162 posts
I hope this project gets more traction. I would love to see a memory safe battle tested sudo or polkit in my package manager without having to install a potentially workflow breaking replacement.
Any wizard here? Fill-C vs Rust? Realistic comments without hype.
Both are great tech but solve the problem of safety differently. I would say Fil-c is great for non-performance-critical (think like somewhere between c and go/java, still very fast) existing C programs where compatibility with the existing program / security is a big concern. think ffmpeg, nginx, sudo. Fil-c: - You have a great existing c program that may have memory bugs, and you wanna make it safer. - Or you wanna…
Earlier quoted context omitted.
Finally reality is catching up with the WASM sales pitch against other bytecode formats introduced since 1958, regarding security and how great it is over anything else.
Warm was great because it was lightweight and easy to target from any language and create any custom interaction API with the host. That's becoming less true as they bolt on features no one needed (GC) and popularize standardized interfaces that contain the kitchen sink (WASI) but these things can still be treated as optional so it can still be used for much more flexible use cases than java or .net
Earlier quoted context omitted.
> hardly any benefit over OS processes, talking over JSON-RPC Hardly any benefit except portability and sandboxing, the main reasons WASM exists?
WASM is only portable if the only thing it does is heating up CPU, given that everything else depends on the host.
I hope this project gets more traction. I would love to see a memory safe battle tested sudo or polkit in my package manager without having to install a potentially workflow breaking replacement.
If you're into Nix, check out https://github.com/mbrock/filnix — not yet integrated & maintained in upstream Nixpkgs, but lets you replace Nix/NixOS packages with Fil-C versions quite easily.
Earlier quoted context omitted.
If you can rely on memory errors panicing before the memory error can have an effect, you're memory safe. Memory safety doesn't require "can't crash".
From a definition point of view that might be right and it’s no doubt a good step up, compared to continuing with tainted data. In practice though, that is still not enough, these days we should expect higher degree of confidence from our code before it’s run. Especially with the mountains of code that LLMs will pour over us.
Earlier quoted context omitted.
Your general point stands - wasm's original goal was mainly sandboxing - but 1. Wasm does provide some amount of memory safety even to compiled C code. For example, the call stack is entirely protected. Also, indirect calls are type-checked, etc. 2. Wasm can provide memory safety if you compile to WasmGC. But, you can't really compile C to that, of course...
Correct me if I'm wrong, but with LLVM on Wasm, I think casting a function pointer to the wrong type will result in you calling some totally unrelated function of the correct type? That sounds like the opposite of safety to me. I agree about the call stack, and don't know about GC.
Here it is in the spec:
> The call_indirect instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must have type funcref. Since it may contain functions of heterogeneous type, the callee is dynamically checked against the function type indexed by the instruction’s second immediate, and the call is aborted with a trap if it does not match.
From https://www.w3.org/TR/wasm-core-2/#syntax-instr-control
(Other sandboxing approaches, including related ones like asm.js, do other things, some closer to what you mentioned. But wasm has strict checking here.)
Earlier quoted context omitted.
I think his argument is that you can have code this: user = s->user; if(user == bob) user->acls[s->idx]->has_all_privileges = true; And this happens: 1. s->user is initialized to alice 2. Thread 1 sets s->idx to ((alice - bob) / sizeof(...)) and s->user to Bob, but only the intval portion is executed and the capability still points to Alice 3. Thread 2 executes the if, which succeeds, and then gives all privileges to…
I understand his argument. Here are the reasons why I don’t buy it: 1. I’m not claiming that Fil-C fixes all security bugs. I’m only claiming that it’s memory safe and I am defining what that means with high precision. As with all definitions of memory safety, it doesn’t catch all things that all people consider to be bad. 2. Your program would crash with a safety panic in the absence of a race. Security bugs are whe…
It is buggy because it fails to check that s->idx is in bounds, but that isn't problem if non-adversarial use of s->idx is in bounds (for example, if the program is a server with an accompanying client and s->idx is always in bounds when coming from the unmodified client).
It is also potentially buggy because it doesn't use atomic pointers despite comcurrent use, but I think non-atomic pointers work reliably on most compiler/arch combinations, so this is commonplace in C code.
A somewhat related issue if that since Fil-C capabilities currently are only at the object level, such an out-of-bounds access can access other parts of the object (e.g. an out-of-bounds access in an array contained in an array element can overwrite other either of the outer array)
It is true though that this doesn't give arbitrary access to any memory, just to the whole object referred to by any capability write that the read may map to, with pointer value checks being unrelated to the accessed object.
Earlier quoted context omitted.
If you're into Nix, check out https://github.com/mbrock/filnix — not yet integrated & maintained in upstream Nixpkgs, but lets you replace Nix/NixOS packages with Fil-C versions quite easily.
I am into nix! it's me and my gf's daily driver. thank you.
Earlier quoted context omitted.
C is safe by the same logic, then? You can write safe code in anything if you don’t make mistakes.
But the definition is what we're talking about, not whether you make mistakes. Of course it's important that safe Rust is checked by the compiler, but that's crucially not part of how safety is defined. I would guess that somebody more on the pulse of C's safety efforts could tell you whether they have a definition of memory safety for C or whether they're comfortable with an existing definition from somebody else.
In short, the definitions are not important. What matters are the risks that you do or don’t run. And if your Rust code contains unsafe blocks, you are running risks that you wouldn’t be if you used Fil-C, which has no such escape hatch. (Of course this goes both ways – your Fil-C code is more likely to fail, safely, with a runtime error due to a mistake that Rust would have caught at compile time.)