101–110 of 157 posts
This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
So I think Go is absolutely not in the same bucket as C, C++, or unsafe Rust.
Earlier quoted context omitted.
Question: why is a union memory unsafe? My meager understanding of unions is that they allow data of different types to be overlayed in the same area of memory, with the typical use case being for data structures that may contain different types of data (and the union typically being embedded in a struct that identifies the data type). This certainly presents problems with the interpretation of data stored in the uni…
Canonical example: union { char* p; long i; }; Then say that the attacker can write arbitrary integers into `i` and then trigger dereferences on `p`.
The union example is not particularly problematic in this regard. Much more challenging is pointer arithmetic through uintptr_t because it's quite common. It's probably still solvable, but at a certain point, changes the sources becomes easier, even at at scale (say if something uses the %p format specifier with sprintf/sscanf).
I never understood why software has to pay for the lack of memory safety primitives in the hardware.
Can you say what hardware could do better? I.e. which kind of primitives do you miss, or would make it easier to develop safer software?
Solaris and Linux SPARC since 2015, for example.
https://docs.oracle.com/en/operating-systems/solaris/oracle-...
https://docs.kernel.org/arch/sparc/adi.html
ARM MTE, as another one,
https://learn.arm.com/learning-paths/mobile-graphics-and-gam...
This site is curious in that in incorrectly categorizes go as memory safe. Perhaps in part because the sponsors are invested in using go and benefit from its inclusion in a list of memory safe languages.
Waiting for the traditional Rust reply.
Earlier quoted context omitted.
I am not sure if you are: 1. attempting to retcon garbage collected languages as not memory safe, or 2. discussing a particular implementation choice of the standard Go runtime that was made because it is not a practical source of bugs (see https://research.swtch.com/gorace , it is not an inherent feature of the language, just the implementation, and it is the right practical choice) But either way: this is the sort…
Why do you think data races are not a practical source of bugs?
Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment.
Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.
Earlier quoted context omitted.
> By definition, C and C++ are memory safe as long as you follow the rules. This statement doesn't make sense to me. Memory safety is a property of language implementations, which is all about what happens when the programmer does not follow the rules. > The problem is that the rules cannot be automatically checked and in practice are the source of unenumerable issues from straight up bugs to subtle standards violati…
First, let me say that I really respect the work you’re doing in fil-c. Nothing I say is intended as a knock and you’re doing fantastic engineering work moving the field forward and I hope you find success. That’s good to know about nasal demons. Are you saying you somehow inhibit the optimizer from injecting a security vulnerability due to UB ala https://www.cve.org/CVERecord?id=CVE-2009-1897 ? I’m kinda curious how…
Reasonable people will disagree about what memory safety (and type safety) mean to them. Personally, bounds checking for arrays and strings, some solution for safe deallocation of memory, and an obviously correct way to write manual bounds checks is more interesting than (for example) no access to machine addresses and no FFI.
Regarding bounds checking, GNAT offers some interesting (non-standard) options: https://gcc.gnu.org/onlinedocs/gnat_ugn/Management-of-Overfl... Basically, you can write a bounds check in the most natural way, and the compiler will evaluate the check with infinite precision (or almost, to improve performance). In standard, you might end up with an exception in some corner cases where the check should pass. I wish more languages would offer something like this. Among widely used languages, only Python offers this capability because it uses infinite-precision integers.
Earlier quoted context omitted.
Can you say what hardware could do better? I.e. which kind of primitives do you miss, or would make it easier to develop safer software?
Bounds checking of pointers, C Machine kind of. Solaris and Linux SPARC since 2015, for example. https://docs.oracle.com/en/operating-systems/solaris/oracle-... https://docs.kernel.org/arch/sparc/adi.html ARM MTE, as another one, https://learn.arm.com/learning-paths/mobile-graphics-and-gam...
Earlier quoted context omitted.
Why do you think data races are not a practical source of bugs?
They are, pity that Rust type system has nothing to prevent them outside a very specific use case of in-memory data structures and threads. Make those in-memory data structures writable via OS IPC and all bets are open, regarding what other processes, or kernel extensions, do to the memory segment. Fearless concurrency is welcomed, but lets not overlook the fine print in systems programming.