we should all be using Rust then :)
This paper's an interesting read, about writing an OS in Go:
The benefits and costs of writing a POSIX kernel in a high-level language
https://www.usenix.org/conference/osdi18/presentation/cutler
Microsoft: 70 percent of all security bugs are memory safety issues
21–30 of 180 posts
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#22Re: Microsoft: 70 percent of all security bugs are memory safety issues
#23> Terms like buffer overflow, race condition, page fault, null pointer, stack exhaustion, heap exhaustion/corruption, use after free, or double free --all describe memory safety vulnerabilities. Page faults are fine. Null pointers are fine; just don't dereference them. Race condition is a much more general term that can cover non-memory races too; perhaps they meant data races.
Yes, I don’t think race conditions should feature in a list of memory safety issues. However page faults can be not fine - on some hardware it can be a hard fault.
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#24Earlier quoted context omitted.
There's a lot of memory safe languages out there that are great choices. Coming from a Microsoft statement, .Net is pretty neat. When your worst case latency/perf requirements don't allow you to have a GC, Rust is another great choice.
What about when you want a concurrency safe language? You can still have concurrency bugs, like race conditions in languages that are only memory safe.
Of all the stories Rust tries to sell me on, concurrency is by far the weakest of all. Rust concurrency is a mess compared to (yes, I'm going to say it) Go.
Async/await are still far away from being anywhere near figured out nor implemented, CSP primitives in the std. lib like std::mpsc are basically DOA/obsolete/half-functioning and tokio/futures are still early alpha.
There's a lot more to concurrency than just compile-time verification of safe usage of a mutex or moving data in/out of a thread. A lot more.
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#25Earlier quoted context omitted.
There's a lot of memory safe languages out there that are great choices. Coming from a Microsoft statement, .Net is pretty neat. When your worst case latency/perf requirements don't allow you to have a GC, Rust is another great choice.
What about when you want a concurrency safe language? You can still have concurrency bugs, like race conditions in languages that are only memory safe.
Rust does not solve all race conditions, unfortunately. Even world domination has its limits! It does solve simple data races, which means that use of concurrency within Safe Rust is indeed memory safe. This is better than what some other languages can claim, such as Go (only the _sequential_ subset of Go is memory safe)!
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#26Earlier quoted context omitted.
There's a lot of memory safe languages out there that are great choices. Coming from a Microsoft statement, .Net is pretty neat. When your worst case latency/perf requirements don't allow you to have a GC, Rust is another great choice.
What exactly is .Net in this context? Every time I think I understand it someone throws a curve ball. Is it c#? Is it a set of libraries?
It’s the CLR (common language runtime) running in a JIT environment.
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#27Earlier quoted context omitted.
Remember, and I think it goes without saying, any rust rewrite of any scope of project is always trivial, and should be talked about as if a full rewrite naturally will be trivial. Proceed.
In the time it took to write this comment I rewrote Windows 10 in rust twice.
[deleted]
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#28Earlier quoted context omitted.
What exactly is .Net in this context? Every time I think I understand it someone throws a curve ball. Is it c#? Is it a set of libraries?
It’s the CLR (common language runtime) running in a JIT environment.
Okay thanks. I could Google that.
So it's code written in C# or VB or another supported language, compiled by JIT to a common bytecode running on a virtual machine and probably a whole slew of libraries that target that VM too.
Okay. I have no idea why I'm struggling so much with that.
Thanks.
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#29To quote the article: ``` Furthermore, as Microsoft has patched most of the basic memory safety bugs, attackers and bug hunters have also stepped up their game, moving from basic memory errors that spew code into adjacent memory to more complex exploits that run code at desired memory addresses, ideal for targeting others apps and processes running on the system. ``` Is all we can hope for in the security game a seri…
It's about increasing the costs to the attacker.
Now a Windows/browser zero-day requires months of research and can be sold for $100k+.
Re: Microsoft: 70 percent of all security bugs are memory safety issues
#30Just a painful reminder that they scrapped Midori[0] their managed Operating System based on Microsoft Research's Singularity project[1]. Even if it only replaced Windows LTSB/Embedded, I'd still prefer an ATM, checkout, or gas station terminal I was using was running on managed code. Doubly so for the next generation of Nuclear Powered submarines[3]. Plus between virtualisation and silo-ed software management ("Apps…
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.)