OpenBSD Disables Intel CPU Hyper-Threading Due To Security Concerns (bleepingcomputer.com) 234
The OpenBSD project announced today plans to disable support for Intel CPU hyper-threading due to security concerns regarding the theoretical threat of more "Spectre-class bugs." Bleeping Computer reports: Hyper-threading (HT) is Intel's proprietary implementation of Simultaneous Multithreading (SMT), a technology that allows processors to run parallel operations on different cores of the same multi-core CPU. The feature has been added to all Intel CPUs released since 2002 and has come enabled by default, with Intel citing its performance boost as the main reason for its inclusion.
But today, Mark Kettenis of the OpenBSD project, said the OpenBSD team was removing support for Intel HT because, by design, this technology just opens the door for more timing attacks. Timing attacks are a class of cryptographic attacks through which a third-party observer can deduce the content of encrypted data by recording and analyzing the time taken to execute cryptographic algorithms. The OpenBSD team is now stepping in to provide a new setting to disable HT support because "many modern machines no longer provide the ability to disable hyper-threading in the BIOS setup."
But today, Mark Kettenis of the OpenBSD project, said the OpenBSD team was removing support for Intel HT because, by design, this technology just opens the door for more timing attacks. Timing attacks are a class of cryptographic attacks through which a third-party observer can deduce the content of encrypted data by recording and analyzing the time taken to execute cryptographic algorithms. The OpenBSD team is now stepping in to provide a new setting to disable HT support because "many modern machines no longer provide the ability to disable hyper-threading in the BIOS setup."
Opt-In? (Score:4, Insightful)
Given the class of Spectre and Meltdown attacks rely on someone else having the freedom to execute code on your hardware, shouldn't something like this be opt-in? There's a whole world of servers out that where Spectre is ultimately completely irrelevant in terms of a security threat, but hyperthreading is definitely not irrelevant in terms of performance.
Re:Opt-In? (Score:5, Insightful)
No, it shouldn't because security should have higher priority over speed. If people want to run their computer in a less secure mode they can do so themselves after making an informed decision and accepting the risks it includes. The default state should be the more secure mode so that it covers everyone.
+1 to the OpenBSD project for putting security above speed.
-1 to intel for putting speed above security.
When you turn off hyperthreading Intel and AMD are much more closer to each other. This is why my next major computer build will be AMD. I will have speed and security.
Re: Opt-In? (Score:4, Insightful)
Re: Opt-In? (Score:5, Insightful)
If we're going to go down this reductionist security-trumps-all argument then OpenBSD should disable networking too.
There's a fundamental difference between I/O and hyperthreading. Without I/O the computer can do nothing. Without hyperthreading it might be a little slower.
Re: (Score:2, Informative)
You should read about OpenBSD's purposes and intentions. They've always been about security, security, security, and anyone going into it should know that.
I mean, just from the Wikipedia article:
" As of February 2018, only two remote vulnerabilities have ever been found in the default install, in a period of almost 22 years - a fact prominently displayed on the OpenBSD website."
"Many of its security features are optional or absent in other operating systems."
"Its developers frequently audit the source tree
Re: (Score:2)
Re: (Score:3)
If we're going to go down this reductionist security-trumps-all argument then OpenBSD should disable networking too. And keyboard and monitor support. In fact it should shut down when it starts, but not before throwing away the disk encryption key and bricking the device. Now it's secure.
The point is that security is a trade-off between what the device allows and what the threats actually are. Crippling a computers performance to mitigate a threat that doesn't exist for a user is wrong. At the very least it should be an option that might disabled by default but can be enabled if the users wants it to be.
I read it as, security trumps speed.
Whether security trumps everything, is a different matter.
Re: (Score:2)
He didn't say "security-trumps-all" he said "security above speed." You just pretended he said something, then attacked the thing he didn't say. You have a bright future as a politician!
Re: (Score:2)
The problem isn't that they are disabling something used by all software in fact many applications just aren't designed in a manner that can take full advantage of hyper threading. The reason is that most desktop applications require input you tell it what to do then it does it and waits for your next instruction these thing can't happen in parallel. Server software that supports multiple users on the other hand is very much capable of benefiting from hyper threading on the server.
Saying that they are cripp
Re: (Score:3)
The highest value is correctness. The computer should correctly perform the desired operation without side effects.
Security is always required for correctness (because if a stranger can alter the operation of the computer, they're not likely to be trying to help you).
Networking will usually be required for correctness. This approaches always-needed when you get ot the kinds of tasks that OpenBSD is used for.
And a ~20% increase in speed may possibly be required for correctness, but usually isn't.
Track records matter. (Score:5, Insightful)
The current release of OpenBSD, version 6.3, has issued a total of 10 patches [openbsd.org] against base since release on April 15th. Four of these are security-related, and six are reliability bug fixes.
Oracle / Red Hat Linux in that time has issued 50 security-related patches [oracle.com], and hundreds more that are classed as bug fixes or enhancements.
Linux is strong because it scales up and down very well, it exploits CPU features for speed to make applications run very fast, it is friendly to new features, and it has the most market share in the POSIX realm. Linux is weak because it has sacrificed security for speed in many cases, and we have Dirty Cow, Towelroot, and many similar problems in userspace - this makes Linux a bad choice for systems that will not receive patches (i.e. phones, IoT devices, embedded systems, etc.).
OpenBSD prioritizes security over speed and flexibility. It does not implement fine-grained SMP due to security concerns, and has a "big kernel lock" that Linux left behind in 2.2. It ignores many well-known standards (i.e. NFSv4). There are many things that you cannot do on OpenBSD, but what you can do is magnitudes safer than Linux.
Android politely stole [undeadly.org] OpenBSD's entire libc implementation (and then ignored it for several years), and IIRC the OpenBSD code is the largest contribution outside of the kernel itself.
OpenBSD is also the home of OpenSSH, which itself is quite secure.
I trust the opinions of the OpenBSD kernel architects, and I will look forward to their patch.
Re: (Score:3)
I'm sure OpenBSD is very secure and probably worth considering for some very specific roles. It's not a general purpose operating system nor capable of running the kinds of software or loads that a commercial Linux dist is.
Re: (Score:3)
I do agree that it's not quite comparable, but I don't know any minimal Linux distribution that implements the equivalent of the OpenBSD base.
Perhaps to be fair, it appears that Oracle's RHCK has been reissued 7 times since April 15th, which is not quite as bad.
I have had several rounds of users who want one of the Red Hat clones for some app, then realize after deployment that avalanches of patches are required for these platforms and balked - easily thousands over a six-month period for a typical system.
Re: (Score:3)
The real question is what needs to be done.
The history of computing is a series of insecure systems working to get faster. Why? Because the benefits of speed outweigh the cost of security.
During this time reasonable security enhancements are put in, to put aside higher cost security risks.
The 1980s a secure system needed a login and password to login, unneeded ports were closed. Open ports needed a password or didn't do a vital function. And trust your floppies.
The 1990s a secure system needed protection ag
Re: (Score:2)
.
+1 to the OpenBSD project for putting security above speed.
-1 to intel for putting speed above security.
Re: ...security should have higher priority... (Score:2)
Another proponent of the USA PATRIOT Act? (https://en.wikipedia.org/wiki/Patriot_Act)
Re: (Score:2)
Re: (Score:3, Insightful)
Lolz. Yes.
Re: Opt-In? (Score:4, Insightful)
Lolz? I can has cheezburger?
Re: (Score:2, Troll)
I don't get your argument.
Some gun safes are a work of art, where some people may want them as part of their own home furniture.
or just having a tall safe where you can keep your other valuables safe.
My parents are not smokers, but they have antique cigar boxes, which they store sewing supplies.
We actually use a lot of things outside their normal intended purposes.
Re: (Score:3)
Your argument seems to be based on the premise that, since nobody else will be executing code on your hardware, you don't need the extra security.
The problem is malware doesn't always run with your permission, or knowledge.
So your analogy would really be more like; Do you have a password on your system? It would be so much faster to access your server if you didn't have to type in a password every time, and you're the only one with access to it anyway, right? Right?
=Smidge=
Re: (Score:2)
Up, up, down, down, left, right, left, right, B, A, start.
NES has networking too (Score:2)
Oops, too late: ENIO Ethernet, Audio, and Keyboard adapter for NES [youtube.com]
Re: (Score:2)
Re: Opt-In? (Score:5, Insightful)
JavaScript in a browser is the ability to run malicious code on demand. If you run a web browser, you use a multi-user computer. Short of something with an air-gap, there aren't any true single-user systems anymore.
OpenBSD is adding a control to let the system owner mitigate if they decide the risk is not acceptable. You are correct in that security can't trump all and that likelihood is part of the risk equation.
Wish list. (Score:3)
It would be nice if the browser could signal the scheduler that it launched a new tab as an untrusted process, causing the kernel to sanitize caches before and after its future time slices (in addition to any sandboxing the browser parent process and the OS were already doing).
It might also make sense if only processes with the same UID could run on different SMT threads on the same core, rather than just turning them off completely.
Re: (Score:2)
That second one sounds like a form of processor affinity [wikipedia.org], and quite possibly could be implemented without too much difficulty.
Re: (Score:2)
Short of something with an air-gap, there aren't any true single-user systems anymore.
Yes on a Windows machine and someone's tablet you'd be right. But this is OpenBSD we're talking about, staple in the server environment. Many such servers are special purpose, they do not have the ability to run unaudited code, and sure as hell aren't sitting there firing off random javascript from the intertubes.
Also while we're at it, let's discuss your Javascript example. The ability to perform a speculative execution attack relies on some deep understanding of the system and the current operating enviro
Re:Opt-In? (Score:4, Insightful)
Yep, I would like to buy a car with no fender or airbags. You simply can't do that, but you can remove them afterwards.
OpenBSD is secure by default. This is a step to keeping it that way and it totally correct that HT is off to begin with. They already said it will be a switch you can twiddle yourself, but the default will be HT disabled.
You can leave your car doors unlocked if you want after you finish the default install and start playing.
Re: (Score:3)
If its something you can turn on and off I don't see the problem with it.
Re:Opt-In? (Score:5, Insightful)
Re: Opt-In? (Score:2)
on slashdot? rtfa? you having a laugh. but this isnt putting speed above security or anything else. its just not supporting a hardware feature. the feature is what it is, and can be disabled whatever they support. -100 openBSD.
Re:Opt-In? (Score:5, Insightful)
Given the class of Spectre and Meltdown attacks rely on someone else having the freedom to execute code on your hardware, shouldn't something like this be opt-in? There's a whole world of servers out that where Spectre is ultimately completely irrelevant in terms of a security threat, but hyperthreading is definitely not irrelevant in terms of performance.
I can't do any better than quote OpenBSD on this:
OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make.
https://www.openbsd.org/security.html [openbsd.org]
Re:Opt-In? (Score:5, Funny)
As you can read in their statement, they want to be secure. Being usable is not one of their priorities.
Re: Opt-In? (Score:3, Informative)
They have the best documentation in the NIX world, and arguably the most consistent userland.
I'm not even a regular user, as OpenBSD doesn't fit my use case, but you're waaaaay off base in claiming they don't put usability as a priority.
After all, having consistent and clear usability is one of if not the single most important aspect of software security.
Re: Opt-In? (Score:4, Interesting)
Atuomagic has its place(the old OpenBSD installer's enthusiasm for not hiding details of disk partitioning was always sort of irksome without obvious benefit; and it has been dropped in newer versions); but (outside of substantially smaller embedded and educational OSes) OpenBSD does atypically well in giving you the ability to know what is going on, not just have a rough mental sketch of where the black boxes and here-be-dragons zones are. Makes it nice to work with after some time beating your head against automagic that isn't working for some reason and is brutally opaque about why.
Re: (Score:2, Insightful)
Read reviews of hyperthreaded performance gain. It's somewhere like 0% or 10%, depending on what you're doing. Not a whole lot. Hyper threading is more like a "silicon trick gone wrong".
Re:Opt-In? (Score:5, Informative)
Re: (Score:2)
Back in the day we used to manually optimize code by "pipelining" it. We knew how many cycles were available between memory access slots, how many cycles the FPU took to complete it's work, and fit all the logic code in-between those critical points.
Nowadays SMT just executes two parallel threads so that CPU resources can be as fully utilized as possible without the programmer or compiler having to carefully optimize for one specific model.
Re:Opt-In? (Score:4, Informative)
There are still programmers who optimize at that level - and then go one further, by pipelining in such a way that the core can execute both threads at as close to full speed as possible. Usually this ends when you're processing data as fast as the L1 cache can prefetch it - with SIMD instructions, you can hit 32 bytes/clock/thread (two 16-byte operations in one clock), while the L1 cache on the current-gen processors can read 64 bytes/clock/core.
This isn't done on every program, or even most programs, and nobody's optimizing their entire codebase to this level, but for stuff like compressors/decompressors, or codecs, yeah, there's still programmers who will optimize all the way down to the metal.
Re: (Score:2)
There are still programmers who optimize at that level
Usually using compilers capable of handling data dependencies, though.
Re: (Score:3)
Re: (Score:2)
Re:Opt-In? (Score:5, Funny)
However, I forgot to add, for OpenBSD, it may not make that much of a difference - they've never been particularly fast, especially on SMP machines, so perhaps the impact on OpenBSD is disproportionately lower and therefore acceptable? Someone should measure this.
Measure? Measure?!!?! MEASURE???!?! Are you fucking nuts? Why would anyone want to actually measure this when we can have a 2,752-message thread based purely on random anecdotes and opinions arguing over whether there's a difference or not.
(Wanders off muttering "Measure. He wants to measure").
Re: (Score:2, Insightful)
Without data, all you have is an opinion.
I don't care about your opinion.
Re: (Score:2)
Without a sense of humor, you're a bore and a horrible person to interact with.
Re: (Score:2)
I totally agree with you there!
It's just a sign that was hanging up where I used to work.
Measure!
Re:Opt-In? (Score:5, Informative)
Re: (Score:2)
A long time ago I read that it's mostly Windows that benefits from hyper threading because it doesn't save states when it does a context switch, making switching tasks much more expensive than on Linux or *BSD.
Re: (Score:2)
It's somewhere like 0% or 10%, depending on what you're doing. Not a whole lot.
So what you're saying is that basically all the hype over Spectre is completely overblown and everyone should just run KPTI and stop complaining about 10%?
Evidentally 10% performance is only important if you can blame Intel, not if you have to blame OpenBSD.
Re: (Score:2)
In the case of heavy floating point computation, hyperthreading is often a net loss. I haven't seen any tests on the AMD version (SMT) yet.
Re: Opt-In? (Score:5, Informative)
Re: (Score:2)
Sigh, I should have known better than to read a Slashdot headline.
Re:Opt-In? (Score:5, Insightful)
My mode points expired yesterday, so you'll have a comment instead.
Why the fuck would you need an opt-in for a security feature?
"Your data are set to be stolen by default. To change the settings please refer to the respective manual"
Why the fuck isn't data mining, spying, advertising(in windows and ubuntu) opt-in, instead everything bad is opt-out
and now we see people asking for security features to be opt-in.
If you are concerned about that administrator that has to flip a value to enable the security holes in his system, it's his job, you don't have to think about him.
You'll have to think about your average joe, who wants to use *BSD or Linux and isn't specializing in infosec or isn't yet familiar with those terms and practices.
(yes, there are people who aren't programmers, who know how to use bsd and linux)
Re: (Score:3)
Why the fuck would you need an opt-in for a security feature?
Security is always a trade-off. There is no perfect security. You always trade convenience and practicality for a reasonably high degree of security. That's why we have things like passwords instead of everyone requiring to take a blood-sample, have the sample sent to a lab and your DNA analyzed for your identity before letting you access your emails. The blood-sample approach would be more secure than the password, so why not make it default?
To use a less contrived example: your computer connects to the In
Re: (Score:2)
The blood-sample approach would be more secure than the password
No it won't be until lots of additional safeguards that you haven't put in your blood sample story. Yours is a fallacy very popular among people who don't really understand authentication. E.g. whole of the country of India [wikipedia.org].
1. The sample could be intercepted on its way to the lab. VS passwords are encrypted on its way, as well as hashed in storage.
2. The lab could clone / keep a small part of blood sample. VS sending passwords in plain text to a third party authenticator service is insecure.
3. A mosquito th
Re: Opt-In? (Score:2)
I don't know(and would be curious to) how large or small the effort required to make this a toggleable on/off, so it's hard to say if it would even be feasible for the project to maintain both versions(given that scheduler fiddling is involved in getting good HT results, since hyperthreaded cores can't just naively be treated as real additional cores, I'd imagine th
Re: (Score:2)
Would like to see a performance test with feature off and on to quantify, on modern hardware, the speed benefits.
Re: (Score:3)
You can opt in by using a different OS.
OpenBSD is the Secure OS, not fast, easy to use, or available to many different types of hardware. It is secure and reliable (as reliability is considered a prerequisite of being secure)
OpenBSD is the OS that your run your servers which are connected to the internet. It is the Armored truck of the OS world.
If you need speed, ease of use, flexibility, hardware support, They are other OS's out there Free and Commercial that will do the trick.
The biggest treat to OpenB
Re: (Score:2)
Re: (Score:3)
I've wondered - would it be possible for the scheduler to schedule related threads together on a core? I mean, if you query the number of processors, it's
Re: (Score:2)
The beepingcomputer article was a little unclear. Apparently this will be controllable via a sysctl call.
Other options considered (Score:5, Funny)
In an interview, Theo de Raadt stated that other measures were considered by OpenBSD to fight the threats posed by Spectre, Meltdown and the new line of harmful code. "There will for sure be a trade-off between cutting edge performance and real security", de Raadt said.
One of the poweful options considered - that would permanently repel all current threats but didn't make it into final release, was making the power supply option off by default.
Re: (Score:2)
The best fix is to make Intel buy you an AMD system to replace your broken Intel one.
Re: (Score:2)
Well, they did try it, but they discovered a vulnerability with Intel processors...
More cores less price (Score:2, Informative)
Its 2018, entry level phones and $50 TV boxes come with 8x 64 bit cores. Not 2 cores split into 4 threads, or 4 cores split into 8.
5 years ago, mainstream laptop was Core i3, 3217U with a cpu benchmark of 2300.
5 years later and the mainstream is Core i3-7100T with a cpu benchmark of 5080
5 years to only double performance, and then the increase comes from upping the clock speed (1.8Ghz vs 3.4 Ghz).
Meanwhile ARM sells tens of billions of processors, and Intel sells 15% of that number and dropping. Intel tries
Re: (Score:2)
5K support? 8K support?
Thats really where Intel is winning.
Intel is out in front with Windows 10 games and the CPU needed to support the most advanced GPUs.
The who, how when and why of the Spectre problem would be the question to fix next gen.
Someone at Intel would have found that early. Not in the wild.
Re: (Score:2)
Re: (Score:2)
There's got to be people at Intel that could attack Intel processors in ways no one else could ever dream of!
4K? Try 4096K (Score:2)
4K? 8K? Those are Atari 2600 numbers. Activision's River Raid was 4K.
By the time ARM gaming devices became mainstream (Game Boy Advance, 2001), games' data sizes had ballooned in size to 4096K or bigger. Even the "multiboot" games, which you could download to the system's RAM through the serial link without needing a cartridge, were up to 256K.
Re: (Score:2)
AC "poor chips" would not be able to support 4K, 5K games as they are now.
AC 'faster gaming GPUs and Windows 10 compatibility." is what is needed for the more fun games at 4K and beyond. Something Intel and Windows can support.
The only problem is who allowed the security problems to not be found.
Re: (Score:2)
"AC a 4K display in 2018 is not super high spec. "
Agreed, hence $50 Android TV boxes support 4k.
"AC "poor chips" would not be able to support 4K"
Agreed, hence $50 Android TV boxes are not running 'poor' chips.
"AC 'faster gaming GPUs and Windows 10 compatibility." is what is needed for the more fun games at 4K and beyond. Something Intel and Windows can support."
I note your use of getout words like "Advanced", "more fun" and so on. Good luck with that.
To me it looks like you're a) trying to limit discussion
Re: (Score:2)
That's all I use my Windows 10 box for. Gaming. Performance is the only consideration there. I do my real work on Linux. What information am I meant to be leaking exactly?
Re: (Score:2)
No, the phones are usually running ARM cores in big.LITTLE [wikipedia.org] configuration where only half of the cores are actually powered at the same time.
Half of the cores are slow but don't draw too much battery. The other half are high-performance cores (wider issue, out-of order and/or higher clock speed) that draw more power.
The mobile phone industry is leading the development, and other applications such as TV boxes are picking up the leftovers that are no longer relevant for the most performing flagship phones -- a
About hyperthreading (Score:5, Informative)
"a technology that allows processors to run parallel operations on different cores of the same multi-core CPU"
Not it's not. It's a technology that allows processors to present a single physical core as two logical cores. Two threads of software can run simultaneously on a single physical core.
It's mostly an optimization of the execution pipeline. When execution in one thread stalls, it can pick up processing in the other thread. It typically boosts performance by about 10-20%. And yes, I can see this could cause problems regarding timing if you can cause a pipeline stall based on a condition you want to test in the other thread on the same core. It'll be hard though. Maybe too hard to justify disabling HT altogether. Providing a switch to turn it off in case an exploit is discovered would be more wise I think.
Re: (Score:2)
Agreed. The OP incorrectly defined SMT.
Crap, what about all my OpenBSD games? (Score:2)
Re: (Score:2)
I remember when Hyper Threading was first introduced, and I noted that a large number of my games (Viper Racing and Dungeon Keeper being notable examples), would run at half speed. I don't mean the framerates were halved, I mean the actual games themselves ran at half speed. It was like a built-in slo-mo feature.
Some applications, like Media Player also suffered timing issues. Disabling Hyper Threading always fixed everything. This went on for years. When the ability to disable HT in the BIOS was remov
Re:About hyperthreading (Score:5, Informative)
general idea (Score:5, Interesting)
The general idea behind these flaws is that one process can flush the cache that another process is using, and testing whether the flushed area is free. By measuring the amount of time these flush/reload operations take, one can determine most or all of the bits of the secret signing exponent or private key when it's being used in the square-and-multiply algorithm, for example.
The attacker needs to be on the same machine. However, the main point is that any attacker program doesn't need elevated priveleges to carry out the timing attack since the attacking process will have access to the same cache that a sensitive program is using. Therefore, any seemingly legitimate program that is currently running could have this attack embedded inside it.
An attack on GnuPG can be mitigated by modifying the square and multiply algorithm, for example, so that it always multiplies. However, cryptographic attacks aren't the only problem - potentially, timing attacks can be carried out on all kinds of software as they slowly leak data.
Only Intel SMT? (Score:2)
What about AMD's SMT implementation in their new CPU's?
Re: (Score:2)
Fuck yeah! Via C3 support!
Dunno (Score:5, Informative)
First of all, it surely looks like OpenBSD developers don't even have a working spellchecker and perhaps they are correct, saying that it doesn't necessarily have a "posive" effect.
However, in all seriousness, I've seen at least two dozens tests of HT and in the worst case scenario it slows down your performance by less than a few percents, however, when we're talking servers, which nowadays run highly parallelized workloads where a single process may span several cores (nginx, mariadb, redis, mongodb, etc. etc. etc.) the performance gain from using HT may reach up to 30%, i.e. you're getting a third of your cores for free, which allows you to greatly cut expenditures and save on cooling.
Yes, HT poses security challenges in a multiuser environment (say, for a hosting provider) where people might run any code they want, however a typical application server almost always runs a tightly controlled software stack, which means your server processes cannot run any foreign code, which means Meltdown/Spectre class attacks might be safely disregarded.
Re: (Score:2)
(nginx, mariadb, redis, mongodb, etc. etc. etc.) the performance gain from using HT may reach up to 30%, i.e. you're getting a third of your cores for free, which allows you to greatly cut expenditures and save on cooling.
That's interesting, I figured databases would be largely I/O bound, not processor bound.
Re: (Score:2)
Depends on your type of work. On our servers (~4K connections per second) we're 100% CPU bound. If you have enough RAM to keep your DB in RAM (we do), only writes might be IO bound.
Re: (Score:2)
They are latency-bound so HT just causes two requests to be outstanding simultaneously, effectively hiding the latency of one request behind another request. UltraSparc T2 was an architecture based around exactly this principle with eight threads per core.
In my experience, if software is well-written (e.g., you make sure you're bandwidth or compute bound), hyperthreads will definitely slow things down. How badly will depend on the exact workload. In all cases enabling hyperthreads will cause your system to
Re: (Score:2)
> I figured databases would be largely I/O bound, not processor bound.
It depends massively on the skill of the person that designed the databases, the indexes, the hardware, and the skill of the query author.
In one of my gigs I was able to take an hour-long reporting job to under a minute on the same hardware just by making it more efficient. (Adding indexes, eliminating temp tables, and unrolling cursor operations.)
I didn't have to buy my own lunch for a week after that. :)
Re: (Score:2)
I've always been kind of skeptical about it on VMware. I've never seriously tested it beyond screwing around on pre-production systems, enabling and disabling it in BIOS and then doing pretty much the same setup operations with VMs. But it sure seemed like performance was generally more even and predictable with it disabled.
But to this day I'm kind of convinced that I need to double up on vCPUs with it enabled vs. disabled, mostly because it seems like VMware schedules workloads as if HT were real cores.
I
Re: (Score:2)
Hyperthreading v. hypervisors is a really difficult and long topic to talk about. There's a lot of information and performance comparisons on the net and in the end it boils down to the type of work that you're doing.
https://medium.com/data-design... [medium.com]
https://medium.com/data-design... [medium.com]
https://medium.com/data-design... [medium.com]
https://www.phoronix.com/scan.... [phoronix.com]
https://blogs.vmware.com/apps/... [vmware.com]
https://blog.heroix.com/blog/s... [heroix.com]
Also, last time I checked OpenBSD is not widely used as a virtualization platform.
Intel took the approach of speed trumping security (Score:2)
Useless security precaution. (Score:2)
Disabling hyperthreading does EXACTLY JACK SHIT. The same flaw applied to multiple logical cores very easily applies to multiple physical cores and multi-socket systems.
Every intel CPU appears to still be vulnerable as shit. Tested on my i3-7320 system and my multi-socket E5-2650 system under Windows. If OpenBSD wants to be 'secure' they need to only allow one logical core, period, and ignore all the rest. That's the only way to mitigate this problem.
The OpenBSD devs just showed a huge lack of logical think
Re: (Score:2)
Says the person that doesn't run multiple operating systems (let alone have over 10 computer systems running at any given point and time.)
BSD test running now. So far, I am able to get data where I should not. Not important data, but it's a step in the right direction. They do have an issue with their scheduler even with HT disabled when it comes to multiple physical cores (because your scheduler is still handling multiple threads across physical cores, not just logical cores.)
Windows is totally owned. Disa
Where's the Exploit? (Score:2)
So far, it seems to be just a theoretical security exploit.
I have no problem with OpenBSD locking it down, it is what they do and it is what the people who are drawn to OpenBSD expect.
My personal belief is that useful constructs like speculative execution and hyper threading are being abandoned for questionable reasons.
Simply dead wrong about Hyperthreading on all CPUs (Score:2)
The feature has been added to all Intel CPUs released since 2002 and has come enabled by default.
My Intel Pentium Anniversary Edition CPUs and Intel Atom CPUs are proof that this carelessly researched statement is simply dead wrong.
Re: (Score:2)
One version is with memory read and write functions which are timed. Another is with floating point registers. This one involves hyperthreading. Just look through the Intel instruction manual and look for categories of instructions which haven't been covered yet.
Re: (Score:3, Insightful)
For some of the recent vulnerabilities, the OpenBSD team, unlike other OS vendors was not informed in advance. So even when one assumes that there is a SpectreNG-variant that uses Hyperthreading, it is not so obvious that it is known to the OpenBSD developers.
On the other hand, knowing that there are more SpectreNG-variants, and not having been informed about the details might make the OpenBSD devlopers even more cautious about any hardware feature that looks suspicious.
Re: (Score:2)
But Intel are not the only ones who have knowledge on Spectre-like bugs.
There are competent security researchers among the OpenBSD developers that might have found another vulnerability; third parties finding vulnerabilities might also decide to disclose them to OS vendors, including the OpenBSD developers, instead of just to Intel.
Re: A SpectreNG-variant that uses Hyperthreading? (Score:5, Informative)
iPhone users:
Settings > General > Keyboard ... set "Smart Punctuation" to Off.
You're killing us with this shit, it's unreadable.
Re: (Score:2)
It's about priority. If there's only one intensive task running, the rest could be dormant long enough for the attack to work. The number of processes isn't so important as how many of them are actively working.
On the other hand, all you have to do is try longer. Eventually, you'll get the timing right.
Re: (Score:2)
What is the difference between "threads" and "parallel operations"? The lead section of the SMT article doesn't appear to be referring to single instruction multiple data (SIMD). Or what other difference did I miss?