111–120 of 180 posts
Earlier quoted context omitted.
And it has MORE reported CVEs than Windows: https://www.cvedetails.com/top-50-products.php?year=2018
Maybe because more people can report them? With Windows you'll be lucky if Microsoft doesn't outright deny their existence.
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…
But does formal verification even help when you're up against side channel attacks on the hardware? Like the branch predictor or DRAM memory access timing.
Rust couldn't solve all of these bugs, but it certainly would have drastically reduced the total amount. The code would also be drastically easier to write and debug. C++17 is still a total mess to write, despite what Microsoft might tell you in their docs. Really doesn't make sense to me, outside of the sunk cost fallacy, why Microsoft isn't pivoting to Rust if they want to write C++.
Microsoft probably has tons of internal libraries that are modified and shared between many different teams spanning multiple orgs. I think a pivot like this is an incredibly complicated thing for a company like Microsoft to perform. It requires multiple years of planning from the ground up to port internal libraries and tooling, train engineers on Rust best practices. Not to mention the tricky business of going arou…
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
Linux is also written in C.
And it has MORE reported CVEs than Windows: https://www.cvedetails.com/top-50-products.php?year=2018
Sort by Vendor: https://www.cvedetails.com/top-50-vendors.php
As an industry we should deprecate all unmanaged code. We've proven time and time again that even very professional and highly scrutinized unmanaged code can have critical data safety faults. Yes, I understand this includes Linux, Windows, BSD, Darwin (iOS, MacOS, watchOS, etc), The Android Runtime, and lots of critical software that runs on top of those systems. We have the tools to write very efficient managed code…
I think that you massively under-estimate the cost of rewriting all that code. Yes, the security flaws are expensive. Rewriting the code would be, I'd guess, at least one order of magnitude more expensive.
Earlier quoted context omitted.
It's also OSS and it is much easier to surface security bugs for Linux than for Windows. In my own research, I have attempted to send Microsoft security bugs only to be told they would be backlogged and reviewed later (which never happened to my knowledge).
> It's also OSS and it is much easier to surface security bugs for Linux than for Windows. Shouldn't then the number of bugs decrease much faster, since they are easier to find? Unless they are introduced at even a greater rate than the ones in Windows.
To 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…
Computer security is a fundamentally asymmetric game. Your entire stack needs to contain zero mistakes and an attacker only needs to find one. Also the resources you would expend trying to find and patch every last hole would break the economics. It is what it is.
If people built with things that weren't made of holes (ie. using memory safe languages), then there wouldn't need to be much effort in the "find and patch" side of things.
Earlier quoted context omitted.
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.)
I have never heard about IoT Core before, only IoT enterprise and LTSC. This would actually have been an interesting choice for the project I am working on right now. 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.
Your MS reps need to be fired if they do not know about IoT Core, or chose not to tell you.
Also, I personally find it best to never rely on a rep from any company to give me the truth about their product line. I will make time to do preliminary research (at least) myself.
Microsoft will ALWAYS push IoT Enterprise over IoT Core because IoT Core costs nothing, and generates no revenue for Microsoft (other than the associated Azure revenue that they hope you spend connecting those IoT Core devices to infrastructure.)
All that said, I recommend looking into IoT Core if it interests you. It is very well suited for certain kinds of use cases.
Earlier quoted context omitted.
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…
> Moreover, verification is done with respect to specific properties that ensure no attacks of a particular kind. 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 executio…
According to them, they, sensibly, are indeed assuming some things to be correct without proof: http://sel4.systems/Info/FAQ/proof.pml
This is effectively the same idea behind Rust's `unsafe`. It represents the things you assume to be true. Of course, when compared to seL4, the scales are massively different. :-)