“The important detail is that in all three of these areas [of security] we have not only been fanatical, but pretty much first.”
Your arrogance precedes you, Sir! Nah, he was about forty years behind on doing the kinds of things he described as “first.” Even for UNIX’s where several security-focused projects (maybe 1980’s) and one commercial product (Trusted Xenix, 1990-1994) preceded them. On security side, the main difference between those projects’ methods and OpenBSD is that the former addresses root causes to provably eliminate problems and the latter does probabilistic mitigations that may or may not work. The reasons for the latter are they take less development effort and have lower performance cost on prevalent, insecure CPU’s. This means OpenBSD trades away security for performance and increased compatibility in those cases. It will always be behind methods in high-assurance security but probably ahead in adoption. The fact that it’s FOSS vs close source like most high-security vendors will help it keep the lead on that.
“Someone on wikipedia has gone through a lot of effort to identify some of our security efforts, and there is the Exploit Mitigation Techniques paper which I have presented at a number of conferences.”
I still think they are worth copying in high-assurance security, too. The older approach was mixing strong stuff like MAC with the regular, security mechanisms in OS’s like UNIX. Just extra layers in practice. I also like obfuscation. The thing I like most about many mitigations in OpenBSD is they sort of combine extra layers and obfuscation together. The other benefit OpenBSD’s work could bring high-assurance security is a starting point for new, highly-secure components. The reason is they have small, carefully-built, well-documented components. That’s a prerequisite for kind of analysis that says “all our bases are covered for X, Y, and Z kinds of problems.”
“hese are Linux developers, basically placing the community in a situation where they have to run a binary blob of unknown code from a vendor, instead of sticking to their guns about open source? I must admit, I just don’t understand some people. They must have much more flexibility to their belief systems than I have.”
(Let me illustrate what a hypocritical asshole he’s being with that statement.)
So, there were some OpenBSD developers trying to put an “open, secure” OS on these gigantic blobs of transistors from greedy, sneaky companies with bad track record of quality and security. The project lead called them out on processor and firmware errata many times. He wanted them to fix the chips, firmware, and/or their documentation. Various people have tried reverse engineering it to figure out how it works in many situations. All that work, with and without tooling, found many problems ranging from undocumented behavior to secret leaks to code execution. OpenBSD lead continued focusing his OS work on these CPU’s from these vendors instead of the slower, open ones that occasionally turned up.
I mean, here are vendors of “open, secure OS’s” placing the community in a situation where they have to run their secrets through tens of millions to a billion transistors of unknown behavior from a vendor instead of sticking to their guns about open, trustworthy components? I must admit, Theo, I just don’t understand some people. You must have more flexibility in your belief system to call out folks making practical choices about risk in software when you do the same thing, if not worse, with hardware. If you and OpenBSD team believe in such principles, then it’s time for everyone in OpenBSD project to buy some Verilog/VHDL books plus “High-Speed, Digital Design.” Practice a while with simulators. Then another fundraiser for OpenBSD’s first ASIC based on Leon3, OpenPITON, or RISC-V. Hell, you could build some of your mitigations right into the CPU like CompSci students and proprietary vendors have been sporadically doing from the B5000 in 1961 up to CoreGuard in past year or two.
“Damien Bergamini joined Jonathan toward the end and got all the bugs out of the driver. We are happy to say that it appears to be working better than the Nvidia binary blob. It is also significantly smaller, and it is very clean source code.”
Excellent work on the software side of the untrustworthy hardware. Now, when will they tackle the hard part? Or will they make a pragmatic compromise doing what they can with what resources they have balancing varous goals of differing priorities? Like Linux folks were doing with different goals and priorities.
“There are many reasons why vendors will not give information out. I believe that all their reasons are a lie to the customer. “
This is true. My studies of hardware indicate it’s a ultra-high-cost development that’s cheaper to steal than build. There’s also patents on about everything conceivable. Hiding everything you can, from the design details to what can infer the design details (eg in firmware), force their opponents to have companies like ChipWorks tear it down for design details. Alternatively, send in spies. What resources and risks these require is high enough that secrecy gives I.P. vendors more time in market before competitors release clones, blocks some new entries that lack necessary experience, and lower number of losses from legal battles. On that last one, Samsung paid about a billion in royalties to Microsoft alone for Android which Microsoft didn’t contribute to that I recall. It’s very worth it to them push this as close to zero as possible.
Changing this requires political action where a massive number of companies (lobbying) and/or citizens (voting) achieve patent reform that stops that crap. My compromise was to limit the length of the patent to essentially the release cycles of products. Example: it would be two years for phones if companies release phones every two years. Tie it to whoever is doing it fastest with a competitive product so they don’t respond by slowing down. Then, either free or paid, open hardware can stand a better chance. Right now, just making it open increases odds of being sued to death or with lots of margin gone.
“Of course we did not set out to create OpenSSH for the money – we purposely made it completely free so that the “telnet infrastructure” of the 1980s would die. But it sure is sad that none of these companies return even a fraction of value in kind.”
I keep wondering if they could’ve accomplished the same thing or close enough by making it a dirt-cheap, shared-source, paid product. Either companies pay every year or they pay for updated versions. They can modify their copy however they want. If cheap enough (eg $1-10k a year), it might be such a small, budget item to many companies that they still bought it. Then, it would’ve been a revenue source for the project. Rinse repeat for a lot of other superior alternatives to common tech that OpenBSD team creates.
“Twice we asked them to cover the travel and accommodation costs for a developer to come to their event, and they refused. Considering that their SunSSH is directly based on our code, that is just flat out insulting. “
It’s flat out predictable. Everyone probably told them about what happens when BSD licenses meet corporate greed, attitude, apathy. It’s why I don’t advocate that license any more. They should’ve done either a paid or copyleft offering if they wanted something from companies. It assumes they’ll act as selfishly as possible only benefiting these projects when they have to. Which they do in almost every case. Exceptions exist but are really rare.
OpenBSD lead continued focusing his OS work on these CPU’s from these vendors instead of the slower, open ones that occasionally turned up.
If one doesn’t take the rhetoric too seriously, it’s easy to see that everybody sits somewhere on the purity/pragmatism continuum. It’s clearly important to the OpenBSD project to support the commodity processors that are actually available. For now that means the x86 family, warts and all, with popular ARM variants in second place. However, the project also supports several other architectures that have much worse price/performance characteristics.
I think RISC-V is the shining hope here. FreeBSD supports the RISC-V ISA to some extent already, but as yet there are no commercially available RISC-V processors that can compete with even very cheap x86 chips on performance. When there are, I have no doubt that OpenBSD will have long since been ported. Do you have any specific suggestions about what OS devs can do to encourage the manufacture of open hardware?
“it’s easy to see that everybody sits somewhere on the purity/pragmatism continuum. “
That’s my view. His was smearing others for making compromises. I just applied his own logic to another area to show he was no different in terms of compromising on openness or security to achieve other goals.
“Do you have any specific suggestions about what OS devs can do to encourage the manufacture of open hardware?”
Several things they can do. One is to start businesses selling their stuff by itself or bundled with other software. This revenue can support them plus hardware projects. For instance, they might pay companies like Centaur or MCST for high-performance design. Another is targeted evangelism toward CompSci folks doing government-funded hardware to build enhancements into open CPU’s. Some already do that. Finally, they might learn hardware skills to make it themselves just like they did OS coding to solve their OS problem. They could even make other hardware for money to pay for tools to make the open chip.
“The important detail is that in all three of these areas [of security] we have not only been fanatical, but pretty much first.”
Your arrogance precedes you, Sir! Nah, he was about forty years behind on doing the kinds of things he described as “first.” Even for UNIX’s where several security-focused projects (maybe 1980’s) and one commercial product (Trusted Xenix, 1990-1994) preceded them. On security side, the main difference between those projects’ methods and OpenBSD is that the former addresses root causes to provably eliminate problems and the latter does probabilistic mitigations that may or may not work. The reasons for the latter are they take less development effort and have lower performance cost on prevalent, insecure CPU’s. This means OpenBSD trades away security for performance and increased compatibility in those cases. It will always be behind methods in high-assurance security but probably ahead in adoption. The fact that it’s FOSS vs close source like most high-security vendors will help it keep the lead on that.
“Someone on wikipedia has gone through a lot of effort to identify some of our security efforts, and there is the Exploit Mitigation Techniques paper which I have presented at a number of conferences.”
I still think they are worth copying in high-assurance security, too. The older approach was mixing strong stuff like MAC with the regular, security mechanisms in OS’s like UNIX. Just extra layers in practice. I also like obfuscation. The thing I like most about many mitigations in OpenBSD is they sort of combine extra layers and obfuscation together. The other benefit OpenBSD’s work could bring high-assurance security is a starting point for new, highly-secure components. The reason is they have small, carefully-built, well-documented components. That’s a prerequisite for kind of analysis that says “all our bases are covered for X, Y, and Z kinds of problems.”
“hese are Linux developers, basically placing the community in a situation where they have to run a binary blob of unknown code from a vendor, instead of sticking to their guns about open source? I must admit, I just don’t understand some people. They must have much more flexibility to their belief systems than I have.”
(Let me illustrate what a hypocritical asshole he’s being with that statement.)
So, there were some OpenBSD developers trying to put an “open, secure” OS on these gigantic blobs of transistors from greedy, sneaky companies with bad track record of quality and security. The project lead called them out on processor and firmware errata many times. He wanted them to fix the chips, firmware, and/or their documentation. Various people have tried reverse engineering it to figure out how it works in many situations. All that work, with and without tooling, found many problems ranging from undocumented behavior to secret leaks to code execution. OpenBSD lead continued focusing his OS work on these CPU’s from these vendors instead of the slower, open ones that occasionally turned up.
I mean, here are vendors of “open, secure OS’s” placing the community in a situation where they have to run their secrets through tens of millions to a billion transistors of unknown behavior from a vendor instead of sticking to their guns about open, trustworthy components? I must admit, Theo, I just don’t understand some people. You must have more flexibility in your belief system to call out folks making practical choices about risk in software when you do the same thing, if not worse, with hardware. If you and OpenBSD team believe in such principles, then it’s time for everyone in OpenBSD project to buy some Verilog/VHDL books plus “High-Speed, Digital Design.” Practice a while with simulators. Then another fundraiser for OpenBSD’s first ASIC based on Leon3, OpenPITON, or RISC-V. Hell, you could build some of your mitigations right into the CPU like CompSci students and proprietary vendors have been sporadically doing from the B5000 in 1961 up to CoreGuard in past year or two.
“Damien Bergamini joined Jonathan toward the end and got all the bugs out of the driver. We are happy to say that it appears to be working better than the Nvidia binary blob. It is also significantly smaller, and it is very clean source code.”
Excellent work on the software side of the untrustworthy hardware. Now, when will they tackle the hard part? Or will they make a pragmatic compromise doing what they can with what resources they have balancing varous goals of differing priorities? Like Linux folks were doing with different goals and priorities.
“There are many reasons why vendors will not give information out. I believe that all their reasons are a lie to the customer. “
This is true. My studies of hardware indicate it’s a ultra-high-cost development that’s cheaper to steal than build. There’s also patents on about everything conceivable. Hiding everything you can, from the design details to what can infer the design details (eg in firmware), force their opponents to have companies like ChipWorks tear it down for design details. Alternatively, send in spies. What resources and risks these require is high enough that secrecy gives I.P. vendors more time in market before competitors release clones, blocks some new entries that lack necessary experience, and lower number of losses from legal battles. On that last one, Samsung paid about a billion in royalties to Microsoft alone for Android which Microsoft didn’t contribute to that I recall. It’s very worth it to them push this as close to zero as possible.
Changing this requires political action where a massive number of companies (lobbying) and/or citizens (voting) achieve patent reform that stops that crap. My compromise was to limit the length of the patent to essentially the release cycles of products. Example: it would be two years for phones if companies release phones every two years. Tie it to whoever is doing it fastest with a competitive product so they don’t respond by slowing down. Then, either free or paid, open hardware can stand a better chance. Right now, just making it open increases odds of being sued to death or with lots of margin gone.
“Of course we did not set out to create OpenSSH for the money – we purposely made it completely free so that the “telnet infrastructure” of the 1980s would die. But it sure is sad that none of these companies return even a fraction of value in kind.”
I keep wondering if they could’ve accomplished the same thing or close enough by making it a dirt-cheap, shared-source, paid product. Either companies pay every year or they pay for updated versions. They can modify their copy however they want. If cheap enough (eg $1-10k a year), it might be such a small, budget item to many companies that they still bought it. Then, it would’ve been a revenue source for the project. Rinse repeat for a lot of other superior alternatives to common tech that OpenBSD team creates.
“Twice we asked them to cover the travel and accommodation costs for a developer to come to their event, and they refused. Considering that their SunSSH is directly based on our code, that is just flat out insulting. “
It’s flat out predictable. Everyone probably told them about what happens when BSD licenses meet corporate greed, attitude, apathy. It’s why I don’t advocate that license any more. They should’ve done either a paid or copyleft offering if they wanted something from companies. It assumes they’ll act as selfishly as possible only benefiting these projects when they have to. Which they do in almost every case. Exceptions exist but are really rare.
If one doesn’t take the rhetoric too seriously, it’s easy to see that everybody sits somewhere on the purity/pragmatism continuum. It’s clearly important to the OpenBSD project to support the commodity processors that are actually available. For now that means the x86 family, warts and all, with popular ARM variants in second place. However, the project also supports several other architectures that have much worse price/performance characteristics.
I think RISC-V is the shining hope here. FreeBSD supports the RISC-V ISA to some extent already, but as yet there are no commercially available RISC-V processors that can compete with even very cheap x86 chips on performance. When there are, I have no doubt that OpenBSD will have long since been ported. Do you have any specific suggestions about what OS devs can do to encourage the manufacture of open hardware?
“it’s easy to see that everybody sits somewhere on the purity/pragmatism continuum. “
That’s my view. His was smearing others for making compromises. I just applied his own logic to another area to show he was no different in terms of compromising on openness or security to achieve other goals.
“Do you have any specific suggestions about what OS devs can do to encourage the manufacture of open hardware?”
Several things they can do. One is to start businesses selling their stuff by itself or bundled with other software. This revenue can support them plus hardware projects. For instance, they might pay companies like Centaur or MCST for high-performance design. Another is targeted evangelism toward CompSci folks doing government-funded hardware to build enhancements into open CPU’s. Some already do that. Finally, they might learn hardware skills to make it themselves just like they did OS coding to solve their OS problem. They could even make other hardware for money to pay for tools to make the open chip.
I really liked this one: