41–50 of 64 posts
Worth re-posting Theo's 2007 note about CPU security bugs again: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2 My hunch is that as they suspected these types of issues is what guided them away from things like AVX and other optimizations.
> "OpenBSD does not use the AVX instructions to the same extent that Linux and Microsoft do" While I love OpenBSD and what they do ... I have to admit, I get frustrated because many times OpenBSD is immune to security vulnerability simply because they don't implement modern tech advancements like AVX. Not being as vulnerable doesn't make OpenBSD more "secure", it just makes them behind the times - like riding a horse…
Software running on OpenBSD can clearly use AVX, but the kernel and core OS doesn't yet, which security wise seems to be the smart move.
Look at SMT, that's still disabled on OpenBSD I believe, which indicate that Intel and AMD have yet to devise a way of implementing it safely. You can enable it, if you need the speed more than security, but I doubt that many does.
Worth re-posting Theo's 2007 note about CPU security bugs again: https://marc.info/?l=openbsd-misc&m=118296441702631&w=2 My hunch is that as they suspected these types of issues is what guided them away from things like AVX and other optimizations.
They also have a limited number of developers and no interest in performance.
Earlier quoted context omitted.
They also have a limited number of developers and no interest in performance.
“[N]o interest in performance” is probably a bit unfair, no? It makes it sound like any patch that brought solely performance would be rejected. But it is certainly true that they have much less manpower than the “competition” and that performance takes a backseat relative to other priorities.
Earlier quoted context omitted.
“[N]o interest in performance” is probably a bit unfair, no? It makes it sound like any patch that brought solely performance would be rejected. But it is certainly true that they have much less manpower than the “competition” and that performance takes a backseat relative to other priorities.
No interest in performance means that, no? If they did what you said and rejected performance patches they’d be actively against performance.
If the performance patches would make the code less secure, they would not implement it.
> "OpenBSD does not use the AVX instructions to the same extent that Linux and Microsoft do" While I love OpenBSD and what they do ... I have to admit, I get frustrated because many times OpenBSD is immune to security vulnerability simply because they don't implement modern tech advancements like AVX. Not being as vulnerable doesn't make OpenBSD more "secure", it just makes them behind the times - like riding a horse…
You might need a box to be as safe as possible, but performance is secondary. Following your car example, some people prefer a safer car over a faster one. If you chose Open BSD you make that explicit choice. Their promise is to avoid technologies unless they are rock solid, even at the cost of performance or convenience (like the forking to LibreSSL).
So it seems that your statement is only true for the base system.
Those days the web browser is the main path for RCEs on a user's desktop. For example firefox on a linux system uses around 25 external libraries, if not more.
Earlier quoted context omitted.
Incorrect. They had explicit permission from the researcher involved to commit when they did. Here's the full discussion, if you want to read it yourself. https://marc.info/?l=openbsd-tech&m=152909822107104&w=2 More directly, from the KRACK FAQ: As a compromise, I allowed them to silently patch the vulnerability. https://www.krackattacks.com/#openbsd It's also worth noting that Microsoft violated the embargo as well:…
I mean, I just disagree with that interpretation of 2018 events. The embargo deadline was extended, OpenBSD violated that. They refused to play ball with the coordinated extension. The researcher is orthogonal to that. Their actions in 2018 are certainly not universally celebrated as a good way to participate in an embargo.
The next time you coordinate a disclosure, you can run it differently.
Earlier quoted context omitted.
I mean, I just disagree with that interpretation of 2018 events. The embargo deadline was extended, OpenBSD violated that. They refused to play ball with the coordinated extension. The researcher is orthogonal to that. Their actions in 2018 are certainly not universally celebrated as a good way to participate in an embargo.
They asked for permission from the coordinator and got it. It's that simple. There's nothing open to interpretation here. The next time you coordinate a disclosure, you can run it differently.