91–100 of 180 posts
It's a pity Modula-2 did not gain wider adoption 30 years ago - it has almost all the memory safety of managed languages and none of the performance penalties. Array bounds were checked by compiler and the only available unsafe operation was deallocate, all other unsafe operations were sequestered into separate module which could be easily isolated, audited, and/or banned as appropriate. Life could have been so much…
It's a pity Modula-2 did not gain wider adoption 30 years ago - it has almost all the memory safety of managed languages and none of the performance penalties. Array bounds were checked by compiler and the only available unsafe operation was deallocate, all other unsafe operations were sequestered into separate module which could be easily isolated, audited, and/or banned as appropriate. Life could have been so much…
Luckily now we have Rust! :)
Earlier quoted context omitted.
I'd strongly prefer that my ATM had no start menu, file picker, online help system, interactive parts of update system, or any of the thousands of other UI apps which could be exploited via touchscreen if accidentally activated. Singlularity would be cool, but I'd prefer smaller footprint to begin with.
Microsoft already have what you're talking about; it's called Windows IoT Core. (This is in contrast to Windows IoT Enterprise, which is the more traditional "Windows Embedded" experience with many of the features you're complaining about. This is mostly because Enterprise customers want to be able to slap their coded-for-a-desktop apps onto a kiosk and declare the job done.)
It's really infuriating how many versions MS is cranking out without clear differentiation between them and even when you talk to MS reps they know nothing about the options.
Earlier quoted context omitted.
Luckily now we have Rust! :)
30 years of pain tho? Plus however many more years it will take to phase out existing C-based code, so another 30 at least.
Earlier quoted context omitted.
Luckily now we have Rust! :)
30 years of pain tho? Plus however many more years it will take to phase out existing C-based code, so another 30 at least.
Earlier quoted context omitted.
Luckily now we have Rust! :)
30 years of pain tho? Plus however many more years it will take to phase out existing C-based code, so another 30 at least.
One reason why we're seeing stuff like the [FirecrackerVM](https://firecracker-microvm.github.io) or [AzureIoTEdge](https://github.com/Azure/iotedge) is that the companies behind them know they will attract privacy-/security-minded customers they might not otherwise have.
There's other reasons as well, but this is just what stands out to me first.
Earlier quoted context omitted.
sel4 shows that an endgame is possible wrt to memory safety, it's formally verfied to be memory safe. It's sitting at ~25 to 1, proof code to implementation code. I think you could probably get that down to 5 to 1 or so by treating a lot of the work they did as a library. The proof covers a full equivalence from abstract spec to machine code, and you could reuse a lot of that. Sort of how it's not fair to include the…
That's not an endgame if the resources required to block an attack are significantly greater than those required to make one. Moreover, verification is done with respect to specific properties that ensure no attacks of a particular kind . The more kinds of attacks you need to defend yourself from, the harder you need to work (and you will miss some). Not saying we're not making steps in the right direction, but no on…
No. seL4 proved functional correctness. It eliminates all attacks, not just particular kinds.
Functional correctness means implementation matches specification. As a corollary, seL4 has no buffer overflows. Proof: Assume seL4 has a buffer overflow. Exploit it to run arbitrary code. Arbitrary code execution is not part of specification, hence implementation does not match specification, leading to contradiction. QED.
Above proof applies to use after free, or any other exploits enabling arbitrary code execution, including methods which are not discovered yet.
Earlier quoted context omitted.
No, just use Rust...
Well, that wouldn't eliminate everything (row-hammer, speculative execution), but it would probably get rid of the most common culprits - buffer overflows and use after free.