[renewiltord]

> On Linux, glibc has AVX-based optimizations for simple functions (string and memory copies) which will store secrets into the register file which can be extracted trivially, so the impact on glibc-based systems is HUGE.

Interesting. I would have expected it to be some amount of worse performance not using AVX. Though perhaps the past throttling effects from AVX-512 and friends made it so it was too complex to manage which instructions to select in BSD.

[pdw]

OpenBSD is not a fast system.

[stevefan1999]

Nor does it needs to. Safety is better than performance anyway

[gerdesj]

"Safety is better than performance anyway"

... unless you need performance. What a vacuous statement!

[renewiltord]

It's trade-off. I have backtesting cluster. No inbound except SSH in-office. Run with `mitigations=off` on Linux. So far all my apes gone nowhere.

[nvy]

OpenBSD isn't materially more secure than Linux, these days.

They've shipped several RCEs over the years, in software included in base, but because the software is not enabled by default they don't update their security slogan.

It gives the impression of an OS that is free of vulns which is not true. The "default install" is not useful for much as IIRC it only has ssh enabled which means their claim of only two remote holes in $time_period is really just a claim against their TCP/IP stack and OpenSSH, not the entire OS.

It's deliberately misleading.

[cosmojg]

I'll take performance over safety any day of the week.

[matrix12]

Rust would love a talk with you...

[stevefan1999]

I am a Rust guy, sorry.

[matrix12]

Then you know Performance and Safety are not mutually exclusive.

[stevefan1999]

They still are mutually exclusive. For example, you don't have built-in bitfields in Rust. You have fat objects that requires heap memory to work properly. Still, there are many kinds of metrics for performance. While the execution performance of Rust is fantastic that it reaches the figures on the ballpark with C and C++, and sometimes even better due to fundamental stuff like borrow rules and strong alias rules and immutability propagation, the developmental performance of Rust is abysmal at best :[ Bunch of concepts to understand, generic and trait bounds, async and Poll, crate orphan rules, ownership and lifetime and although my prior C++17 knowledge did help, but consider in the picture for a complete newbie, they are no easy feat to challenge.

The compilation performance of Rust is also unsatisfying too with right even though it got the package manager right. I remember sitting 15 minutes to build my first ESP32 RISC-V firmware in Rust and still have to wait 2 to 3 minutes for consecutive debug builds. All of that on a Ryzen 3700X, maybe machine issue idk.

[ksec]

It used to be very slow ( or for some people fast enough ). But I wonder if that is still the case in 2023. This reminded me nagging phoronix to do another BSD reviews.

[hulitu]

Depends on the architecture. On Sparcstation 20 circa 2000 OpenBSD was way faster than linux.

[matrix12]

configure comes to mind as a great example of this.

[loeg]

Yes, it does come with worse performance (for those functions).

[queuebert]

Full pipe string copies are not a frequent task for any OS.

[dralley]

String comparisons are, though.

[comex]

Large memory copies, however, are quite frequent.

[queuebert]

For what purpose? That seems pretty inefficient.