4 ms·
For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low l
by atoav 3y ago
For me it feels just wrong? Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive.
If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? So now you got bad software in a sandbox that may or may not be safe and is less performant than the low level variant. Maybe the software is bad in a kind that allows abuse despite the sandbox, congrats now your baseband lies to you.
The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. Embedded programming sucks, but we have Ada, we have Rust and we have a chance to do things that are both safe and performant.
- eptcyka 3y agoNobody is attacking interfaces of plane SBCs the way mobile basebands are being attacked out in the wild. They defensive architecting and programming for aerospace most often is entirely different from the defensive programming of things that have to contend with malicious input.
- bdd8f1df777b 3y ago> when we obviously know how to write safe software in other spaces in the low level? Think anything space, aviation or automotive. I seriously doubt that those software is near any levels of safe. They are just not attacked as often. > If your remedy to writing bad software is "just put it into a sandbox", then who says that sandbox isn't bad software as well? Chromium has high quality coding, but they still sandbox their own code whenever they can. Security vulnerability results from the limit of humanity, so it cannot be eliminated by just willpower. And to answer your question directly, * Writing a sandbox is easier to get right than many other software. * Even if the sandbox itself is badly written and therefore has vulnerability, it must be combined with the vulnerability of the software it protects in order to achieve any attack. So sandboxing something always increase the difficulty of attackers and is a worthy investment from the viewpoint of security. > The solution I like is to use strictly typed languages, formaly verified compliers, a ton of tests and fuzzing and above all: avoiding unnecessary complexity. The relationship between these and sandboxing is not exclusive. One can and should do both of them.
- dvdkon 3y agoIt's just as much software engineering as it is "politics". Baseband vendors could put in as much effort as aviation manufacturers, but they won't. The status quo of overcomplicated, insecure, buggy software is hard to change. So the only tenable approach is one that relies as little on baseband vendors cooperating.
- LoganDark 3y ago> Why would we high-level-sandbox a basic functionality when we obviously know how to write safe software in other spaces in the low level? Why would we sandbox code against vulnerabilities rather than simply writing code without vulnerabilities? Because writing code without vulnerabilities is not possible to achieve 100% of the time. I love Rust as much as the next guy, but you need to know how to use it, too. We're back to "just do it perfectly" again: write perfect code, using perfect languages with perfect compilers. In order to know how to do that, hire perfect employees. In order to hire perfect employees, you need a perfect interview process, etc. I'm sure this would be easy in a perfect world. But do you have any idea how unrealistic this prospect is? About why you can't just place your trust in being able to write perfect code that has no bugs, and about why defense in depth is so important? If you have no sandbox, you have to write code that contains zero vulnerabilities. If you cannot perfectly guarantee the complete absence of bugs, you cannot perfectly guarantee that your code contains zero vulnerabilities.