Thoughts on Conway's Law and the Software Stack
blog.jessfraz.com
blog.jessfraz.com
After posing a hypothesis, the post talks about security and process isolation. But the problems raised aren't in line with the hypothesis: the challenge in these cases isn't "insufficient communication" between the levels of the stack, but rather a discrepancy between the abstraction's actual behavior vs. a human's desires and expectations about big-picture topics.
These abstractions often compromised by information leakage through side effects that executing code can observe or deduce, leading to the class of vulnerabilities that have long been around, but have received far more attention since Spectre.
Protecting against timing attacks and other side-channel attacks requires the observable state of the system to not vary due to execution in a different security domain. Timing attacks are particularly frustrating, because processes can estimate their execution time even without external timers, so it can compare the time taken between different calls. Cryptographic operations often take special care to avoid leaking information through timing, but the same discipline isn't commonplace in system calls or userland code. And shared caches will leak info in timing but greatly improve performance.
Hardware isolation is an effective solution for curbing timing attacks for systems that don't communicate over a network. It's not sufficient in the case of networked systems, because the network and its connections form another source of observable state that's likely full of unrelated side-effects.
Isn't the thesis of the post that that exact discrepancy is due to insufficient communication between the people at different levels of the stack?
An abstraction is an interface between two levels of the stack, right? I think the thesis of the post is that the exact discrepancy you describe, between the abstraction's actual behavior and the desires and expectations of the people one level up, is due to insufficient communication between the people one level up and the people implementing the abstraction's actual behavior, which due to Conway's Law are separate groups of people.
You mention "information leakage", but that's leakage between software components at different levels of the stack; perhaps you have that confused with the "insufficient communication" referred to by the post, which is between groups of people at different levels of the stack?
Surely the era where it was common for multiple users to be logging into one computer was long enough, and central enough, that it still informs a great deal of current hardware design.
Or you can buy a dozen cheap systems and run each of your customers on one of those. There's still the opportunity for side channels there - We were finding timing exploits in crypto libraries long before VMs.
It's an arms race, and we're neither winning or losing, but as the market grows the spread gets wider.
...and that upended everything about CPU multi-tenancy.
Well, it was true when the abstract machine described by a CPU datasheet was closer to the one actually running the code. But people decided it was better to run all the code through a real-time optimizing interpreter, and didn't check the interpreter for security.
We'll get secure machines back at some point. One or two manufacturers may die on the process.
https://en.wikipedia.org/wiki/Trusted_Computer_System_Evalua...
http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A...
https://ieeexplore.ieee.org/document/213271
https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653...
Industry and hackers just ignored this stuff for different reasons. The TCSEC certification, despite its problems, cause those along with all kinds of vulnerabilities by forcing systematic design and evaluation with methods proven to get the job done. NSA pentesters shredded most commercial products during evaluation. Today's still do for lots of F/OSS, too. The B3/A1, or high-assurance, systems took 2-5 years of pentesting with hardly any issues found. Details were published in conferences and products marketed. Aside from formal verification, only apathy explains security-focused folks totally ignoring all that outside CompSci which often cites it.
What's causing the problem Jessie Frazel speculates about is merely that people running companies are incentivized to not give a damn in all kinds of ways. That includes adding insecure features to drive sales (mgmt bonus), cutting or ignoring security along with other costs (mgmt bonus), and no liability for damage that happens (externalities). The solution is, like TCSEC or DO-178C, carefully-designed regulations that force them to use known-good methods to knock out preventable problems. If they don't, the fines are higher than the cost of preventing them.
That and/or liability in court for anything they could afford to use. Obviously, we might make provisions for smaller businesses that had less money for consultations. A lot of what we see in the marketplace, though, is avoidable with almost no effort. Free guides experts keep up to date on the basics might constitute the minimum with liability going up based on what resources they had available to do more. Reusable solutions and solution providers would show up to make it easier like they did for both TCSEC and DO-178C (still do for it). There's also existing offerings that are more secure-by-default which can be extended. On native side, you have stuff like OpenBSD, lwan web server, and TrustDNS in Rust. Even PHP has Airship CMS to help people throw web apps together with fewer problems.
These companies will come around when they're forced to come around with the threat CEO's, project managers, and others will loose their money and/or position for not having security. Before that, they'll try to bribe, argue in court, bullshit, and so on. There will be some fight to get there. Lots of improvements such as no telnet on routers can come with almost no money spent. We might make progress by just reminding decision makers during those battles how inexpensive certain improvements really are vs the regulatory and legal actions.
Are there specific hardware mechanisms in "real" server processors that can provide high performance without side channels? What are they?
One of the simplest methods, though, is focusing the leak-proofing on the barrier between partitions handling secrets and everything else (esp w/ comms capability). Then, you just make sure you have trusted, hard-to-hack code on as much of the system as possible. No web browsers and such. Safe, system language with pointer and overflow protections along with performance hit that comes with. Otherwise, back to physical separation. I used that with KVM switch back in the day.
Here's their statement on vulnerabilities: https://www.mips.com/blog/mips-response-on-speculative-execu...
One I can think of is cache partitioning by process id and security context. Not sure any CPU implements that. We can also use cpusets to assign processes to physical cores or sockets, limiting how much opportunity you have to see what other processes are doing. This can even increase performance for high priority processes because they may compete less with other processes that get fewer cores.
Now that I mention that, I'll probably give Slack a single core.
You can try to alleviate some problems but in the end this lack of communication is also what create the success. It allows for "slack". It build learning.
We have "incidents". This is good. This is where we can learn. What we need is to understand that and learn better.
I suppose jessie knows John Allspaw...
But yeah, communication won't scale.
Like Apple?
AWS has their own ARM processor (Graviton), and hardware designs. All completely proprietary. GCP has TPUs, and so-on.
Consider for example Windows 2000. In the years during which it (NT5) was developed, Microsoft merged security and directory teams. That yielded Active Directory, and it was a resounding success. Other companies, like Sun, failed to see the brilliance and importance of this, and treated their directory products as a cash cow -- that it was then an ever decreasing cash cow wasn't good, but hey, milk it for all it's got.
Now imagine Apple owning the whole stack. But they too could make a mistake like, e.g., Sun's, or they could get do better than Microsoft in my example. There's no guarantee either way, and it's not necessarily easy to spot the mistake / opportunity as it comes up.
Besides, owning the whole stack is really difficult. Once you get to where you own 90%, the benefit of each additional 1% is more and more outweighed by the cost.
The way Bose succeeds is that they are willing to market to the majority tastes, and they are willing to use vertical integration to deliver a great user experience with ok to good performance using cheaper hardware.
I have no idea if this can apply to security and Conway's Law. Apple is serious about security, because they are serious about payments. They are willing to put clean architecture before backwards compatibility.