281–290 of 480 posts
Earlier quoted context omitted.
Yes, UNIX was adopted by the corporations and brought C with it. Some people don't get it that before it happened we were happily using other systems programming languages way safer than C.
(For the record, grandparent originally ended with "Some people just don't get it")
Earlier quoted context omitted.
You are missing the forest for the trees. Grandparent is saying "replace all C with Rust" and you replied with "but look, Rust programs rely on glibc! It's unsafe!" Yes, Rust programs can be affected by this. But only because they call into C at a lower level, for the libc layer. If glibc was in Rust it would provide security to all application, including ssh or curl which aren't in Rust. Also, extern "C" is for C FF…
Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. You're talking about the forrest - while we're talking about how making trees from scratch is difficult and messed up no matter how you go about it. At some point, you have t…
A bit higher up:
It was clear when Hoare stated on his speech in 1980:
"Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to - they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- https://news.ycombinator.com/item?id=11110456
... which directly contradicts the "no one" part.
Has anyone actually tried the PoC on their systems? I will test on CentOS 6 and 7 after I have had my coffee. Anyone willing to volunteer to test on Ubuntu and Debian? Here is CentOS 7 [ 389.064412] do_general_protection: 159 callbacks suppressed [ 389.064416] traps: CVE-2015-7547-c[1161] general rotection ip:7fa6b0d8fd67 sp:7ffdaf034a30 error:0 in libresolv-2.17.so[7fa6b0d87000+16000]
$ ./CVE-2015-7547-client
[1] 15697 segmentation fault (core dumped)[flagged]
P.D. It irks me that Rust slogan is 'zero cost' abstraction. There is definitely a cost. The memory model is more complex than C. One shouldn't try to hide the tradeoffs behind 'marketing' slogans.
Earlier quoted context omitted.
> Every engineering decision has costs as well as benefits. Can you elaborate, in detail, what the costs of memory safety are?
Memory safety costs 10% in execution speed and takes 50% more effort to develop, a fair trade-off anyone can take on behalf of their customers. Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding.
That doesn't match my experience. Source?
> Shortcomings of C are offset by many eyeballs law and the security life-cycle processes so much so that we can afford to safely abandon most organized auditing as well as any defensive coding.
In effect, you're saying we shouldn't care about security vulnerabilities, because they'll be patched. That may be true for your projects. It's not true for many organizations.
Earlier quoted context omitted.
>Patch ASAP What exactly do you patch? Say you have a TCP server, written in Python or in Go. Do you have to update Python and Go ASAP then and recompile the Go server? Custom compiled Apache, Nginx? Recompile those? That's a lot of work..
Unless you are linking statically (and I don't really understand why you would) you update glibc and that's it. This question had me feeling kind of old. Does nobody learn what shared libraries are anymore?
I bet this bug will live on forever in people's Docker stacks.
Earlier quoted context omitted.
> Do some low level Rust programming and then do some low level C programming. It's hardly any safer, because it can't be safe at such a low level without a performance penalty. In the capitalist reality we live in, that is a cost no one will pay. I do a lot of low-level Rust programming and a lot of low-level C programming. I don't know what the performance penalty you're claiming exists comes from. Can you elaborat…
A little defensive, maybe? I never claimed Rust was slower than C or that it had a performance penalty (because you should use unsafe). Actually, I pretty much said the opposite. I said they were the same. I was trying to highlight the fact that unsafe Rust and C are not that different when you're doing bitwise operations on bare metal. I was wanted to drive the point that additional abstractions are undesirable at t…
Can someone give me technical reasons why this world isn't possible: Parts of the linux kernel or glibc or any other critical C code gets replaced by rust code little parts at a time, which is also calleable from C ( https://doc.rust-lang.org/book/ffi.html )? That way these libraries could be made safer in a controlled and incremental manner. And to reiterate I'm asking for technical limitations, not political or dog…
You can't just pass a Vec to some C code and expect it to work. The reality is that you're going to end-up writing a lot of C-like Rust - Which either acts on C types directly or converts them to Rust types and then does things to them and converts them back. Either way, the safety is largely lost due to this because C types are not going to be safe.
You also can't use any inline C functions or preprocessor macros in your Rust code, meaning that the interop between C and Rust isn't really that good - FFI lets you call functions, but functions only make-up a part the C API. The rest would have to be duplicated in Rust and kept up-to-date, which is a huge development burden and very error prone.
And when you're finally "done" and all the C code is gone, what you're left with is just a lot of C-like Rust, communicating with each-other through the C API using C types with unsafe code everywhere. Essentially C but in Rust form. You'd have to do a ton of refactoring to turn this into anything like idiomatic Rust, and you can't do that refactoring till all the C code interfacing with that Rust code is completely gone so you can stop supporting interop with C.
The bottom line is that it you could do it, but it won't work well because it's missing the big picture - If you don't write Rust code like Rust, then you don't get the safety guarantee's, and you can't do that if you're trying to recreate a bunch of C interfaces in Rust. C interfaces are not safe in the way that Rust would want them to be safe. It's the same reason why you can't write a converter to convert from C to idiomatic Rust - You have to design the system differently to get the gains from Rust, which is a non-trivial thing to do. Rewriting small parts in Rust isn't going to result in the design differences that you need, and the interop between Rust and C isn't very good, leading to lots of problems while you're dealing with both languages in the same code base.
Earlier quoted context omitted.
> How would mmap be any different if it was implemented in Rust rather than in C? You need unsafe to implement it! The safety mechanisms are practically useless at such a low level. They're definitely not. The power of Rust is not avoiding all `unsafe` ever, but wrapping that unsafe into finite-scope, safe wrappers. Something like mmap would presumably interface with the OS's internal memory management routines, whic…
It seems hard (impossible?) to write a safe, full-featured mmap wrapper in Rust, because of the potential for multiple processes sharing mutable access to the memory and defeating Rust's aliasing checks. Maybe you could separately map shared RefCells to guard the pages returned by the mmap wrapper? If the region is backed by a file, you'd need to check those RefCells on every IO access too, though.
Examples would be:
* read-only: &ROMemMap -> &[u8]
* read-write: &mut RWMemMap -> &mut [u8]
* write-only: fn set(self: &mut WOMemMap, i: usize, b: u8),
or more generally: &mut WOMemMap -> &mut [WriteOnly] where WriteOnly has fn set(&mut self, T)
Now for the shared case, consider this: aliasing rules can be avoided with atomic operations, i.e. Arc is shared and can be safely (atomically) read/written by multiple threads.
In the multi-process case, you could provide an atomic API, although we don't currently seem to expose byte-level atomics (likely not present on some platforms) so if you wanted to write a demo you'd need to use the unstable intrinsics atm.
FWIW restricted to single-threaded code, this results in the Cell get/set API which is not hardware-atomic but cannot overlap with other accesses to the same memory, as Cell doesn't implement Share so any threading abstraction will block you from doing any kind of sharing of Cells.
That is, you can share &[Cell] pointing to any bag of bytes that sits in read-write memory, and anything in the same thread can read or write to it, safely.