More misdirection away from capability based security. 8(
I was hopeful we'd be transitioning by now.... it's at least another decade out.
The Case for Memory Safe Roadmaps
291–300 of 427 posts
Re: The Case for Memory Safe Roadmaps
#292"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.
You can have underflow/overflow trapping today if you want it in C++. Most people don't use it, at least not in release builds, because of the performance cost.
Re: The Case for Memory Safe Roadmaps
#293Earlier quoted context omitted.
Language wise, Python is basically just Perl with its arms cut off and bunch of makeup added. It's just very popular in the scientific community, so they have to add it.
Python does not have a lot in common with Perl language-wise, so this seems an odd statement.
Python was based off Perl, so yes it does have a lot in common with Perl.
Re: The Case for Memory Safe Roadmaps
#294"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.
most consumer operating systems are inherently non-deterministic which I put right in there next to undefined behavior (some people say it is a different thing).
It is a different thing. Non determinism is different to undefined behaviour.
Undefined behaviour can cause miscompiles which can break the expected logic of a program. In the worse case, maybe the compiler optimises away your password validation because it has decided that the failure branch is undefined behaviour.
Non determinism can lead to logic bugs, but it can't magically introduce new logic into the program like UB can as part of optimising
Re: The Case for Memory Safe Roadmaps
#295Earlier quoted context omitted.
Absolutely not. You’re confusing it for Spectre, probably.
The article mentions: > Memory safety vulnerabilities are coding errors affecting software’s memory management code in which memory can be accessed, written, allocated, or deallocated in unintended ways. How can you do any of this without software running in the local machine? Honestly asking.
[deleted]
Re: The Case for Memory Safe Roadmaps
#296Earlier quoted context omitted.
Absolutely not. You’re confusing it for Spectre, probably.
The article mentions: > Memory safety vulnerabilities are coding errors affecting software’s memory management code in which memory can be accessed, written, allocated, or deallocated in unintended ways. How can you do any of this without software running in the local machine? Honestly asking.
Sending network packets. Like, I send you a big array of bytes and you write it to a small buffer and therefore I overwrite unintended data.
Re: The Case for Memory Safe Roadmaps
#297Earlier quoted context omitted.
Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…
>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?
Objective-C?
Plus everything that needs to directly interface with the above languages. So many Python libraries that are one "funny integer" away from a nightmare debugging session.
Re: The Case for Memory Safe Roadmaps
#298Earlier quoted context omitted.
Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.
This is a common conception, and I agree to a point. However, interfaces matter. At the interface to _literally any_ system call, unsafe starts to creep out. Either in the wrapper implementation, or in the interface _to_ the system, or even leaking through the wrapper to the caller. At that point, if we have to re-wrap everything in rust to hide the unsafety of the interfaces to the system (sockets, shared mem, etc e…
C++ makes it very difficult to write safe interfaces. You can't expose references, nor spans, nor variants, no shared_ptrs to things that can't be thread-safely overwritten, nor any standard library containers nor a lot of other things. And even if you only use whatever few interfaces remain safe, the interfaces you create are unsafe by default too. As a result, these unsafe interfaces are everywhere.
I'd contend that using Rust for anything nontrivial results in MaybeUninit & co being common.
Re: The Case for Memory Safe Roadmaps
#299"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.
You can have underflow/overflow trapping today if you want it in C++. Most people don't use it, at least not in release builds, because of the performance cost.
The performance cost exists largely because software doesn't try to check for it, therefore no one tries optimizing those checks away.
Re: The Case for Memory Safe Roadmaps
#300Earlier quoted context omitted.
Rust certainly performs runtime bounds-checking as well as some other tasks, so there is runtime code (even if it's just compiled into executables.) If you want features like async (standard in many language runtimes) you're also going to have to pull in some kind of external runtime dependency. And everyone doing high-level web-style development seems to drag in something like tokio.
> Rust certainly performs runtime bounds-checking as well as some other tasks, so there is runtime code (even if it's just compiled into executables.) I don't think I've ever seen anyone reference "C with bounds checks enabled" as "having a runtime". Does having stack probes also imply having a runtime? I guess I'd be less surprised if it had been worded as "some mitigations/features have a runtime cost". > If you wa…
For sure C programs have a runtime. I'm debugging an issue right now that is to do with Windows not shipping VCRUNTIME140_1.DLL on out-of-the-box or old versions of Win10, so in that case it's very clear because you can make C programs that won't start due to a missing runtime library.
The runtime isn't all that large but every OS has one. On UNIX it's spread over libc, libpthread, libgcc, libm and so on.
On Linux stack probes usually have some support code in libgcc and/or glibc, if I recall correctly.