We are pleased to announce the official release of OpenBSD 6.4. This is our 45th release. We remain proud of OpenBSD’s record of more than twenty years with only two remote holes in the default install.
As in our previous releases, 6.4 provides significant improvements, including new features, in nearly all areas of the system.
OpenBSD 6.4 by default disables simultaneous multithreading and hyperthreading in intel CPUs.
Theo explains:
SMT is fundamentally broken because it shares resources between the two cpu instances and those shared resources lack security differentiators. Some of these side channel attacks aren’t trivial, but we can expect most of them to eventually work and leak kernel or cross-VM memory in common usage circumstances, even such as javascript directly in a browser.
There will be more hardware bugs and artifacts disclosed. Due to the way SMT interacts with speculative execution on Intel cpus, I expect SMT to exacerbate most of the future problems.
More – https://undeadly.org/cgi?action=article;sid=20180824024934
project_2501,
I think we’re still reluctant to come to terms with just how widespread these kinds of vulnerabilities are. It’s tempting to just dismiss/ignore the problems and assume someone will fix it with a simple update. After all, vendors are eager to say they have a fix. But these have the potential to overturn decades worth of SMP + superscalar microprocessor evolution. ASLR is broken, speculative execution is broken, SMP cache sharing is risky. Chances are agencies like the NSA have more exploits we don’t know about yet.
So where do we go from here? I think the long term answer is FPGAs. It won’t be an easy upgrade, but I don’t see a way to fix current architectures without throwing away many of the performance gains that make modern processors faster per clock because it’s the performance gain itself that leaks the information.
FPGAs are only faster for domain specific problems. Once you code a CPU you are slower than a fixed architecture etched directly in the silicon. Maybe you are thinking of reconfiguring the FPGA every instruction type, but that would be really slow.
Exploits will leak information as well so that is probably the rescue. It won’t be 100% secure and no system is.
lapx432,
Keep in mind that meltdown/spectre are *hardware* flaws that violate the security of otherwise correct software. Side channels become possible due to the hidden information CPUs store to predict outcomes and achieve superscalar performance. FPGAs don’t achieve speedup through speculative CPU execution, their pipelines are fixed and they run parallel algorithms deterministicly in constant time without leaking state information. This is why I promote them as a long term successor.
Edited 2018-10-20 06:40 UTC
Then shouldn’t we be using ASICs for those rather than FPGAs? If we’re going to have domain specific processors for domain specific problems, programmability would be an unnecessary overhead.
kwan_e,
Of course these Application-Specific Integrated Circuits (ASICs) are more efficient in silicon, but unlike Field-programmable gate arrays (FPGAs) they’re hard coded and not reprogramable.
The benefit of a CPU is that it can run domain specific software on a generic CPU. Domain specific ASICs, although unbeatable at performance, are impractical for replacing software. In some cases, like bitcoin mining, it’s worth it to build hard coded chips to run tasks as fast as possible, but it would be hard to justify distributing software as custom ASIC chips in the general case.
This is where FPGAs come in, the explicit parallelism offers a huge performance boost over sequential processors. While they don’t achieve the hardcoded performance of an ASIC, the fact they are reprogramable enables them to be used generically in contexts where we’d use a CPU.
FPGAs need to evolve a bit further to address technical requirements, but this is the direction I believe we should be moving in.
Couldn’t they limit HT to threads of just one application allowed to share a core, wouldn’t that deal with potential security problems?
zima,
The way to solve it is to always run the complete code path for all cases and not make a determination until the very end so both paths are indistinguishable for cache and timing side channels leaks. Same database calls, same number of password hash iterations, etc. It’s doable, but not something many of us pay attention to as software developers.
I’m not suggesting these risks have anything to do with openbsd’s reasons for disabling SMP since I haven’t read their specific reasons, but just adding them to the discussion.
The new unveil syscall is really awesome! I’m excited to start using it.
Good news!
and so easy to install, and to patch.
I’m downloading the install64.fs file now, to put on a usb drive. Since they don’t sell the CDs more, I’m hoping OpenBSD fans and users will donate to the OpenBSD Foundation.
That is nice to keep supporting the i386 architecture unlike Linux Mint and others who dropped it long ago. There will be i386s 10 years from now on the market, all those PC104 base industrial rigs, security systems which needs spare parts.
I know Theo’s opinion of the raspberry pi, but hopefully the support will happen once. I prefer running BSDs lately on everything instead of garbage(d) infested Linuxes.
OpenBSD FUD warning! Linux Mint right up to current version 19, Tara, is completely available in i386 versions.
In principle I agree. However check the detail because the 80386 is no longer supported by OpenBSD but the 80486 is. There are a few instructions missing on the 386 which apparently make a significant performance difference.
Also from more recent experience, with a P3Mobile based laptop – there can be gaps in the instruction set which prevent useful software from running even when the O/S seems fine. This conundrum applied to both ANTIX linux (a variant of Debian) and OpenBSD; and left me struggling for a web browser. Firefox-ESR on OpenBSD (6.3) got there after much trial and error. Dillo works well of course, for some purposes.
Edited 2018-10-19 09:07 UTC
Lolwut? Are you trolling or what? ‘Cause when I go to the Linux Mint download page, I can download the 32-bit version just fine.
i386 and 32-bit are not interchangeable terms. i386 specifically refers to the Intel 80386 architecture. i486 is the 80486 series, i586 is the original Pentium. All of those are 32-bit systems, but a 32-bit OS can drop suppport for any or all of those series in favor of only supporting i686.
Even Slackware dropped support for anything less than a 486, and may drop that with the next release or so.
That’s not entirely accurate when you say Slackware dropped i386 support for i486. The Linux kernel itself doesn’t support i386, so no Linux distribution (released in the past few years) can support i386.
Any Linux distro claiming to support i386 is actually providing a 32-bit build for i486 or newer, typically i686.
You’re right, I did make it sound like it was a decision by the Slackware project which is not correct. My point was that even the oldest surviving distro no longer supports 80386 machines.