Earlier quoted context omitted.
Don't know why you're comment is grayed, we absolutely need heavy monetary penalties for the worst kinds of data breaches. The abstract idea of a class action lawsuit isn't enough, even after the Equifax breach.
Is there anything about how breaches are currently remediated that might contribute to better outcomes than if we adopted a higher and harsher penalty system? It seems like it might create some perverse incentives as the risk escalates.
OpenBSD was right to disable hyperthreading [video]
271–280 of 284 posts
Re: OpenBSD was right to disable hyperthreading [video]
#272Earlier quoted context omitted.
Don't know why you're comment is grayed, we absolutely need heavy monetary penalties for the worst kinds of data breaches. The abstract idea of a class action lawsuit isn't enough, even after the Equifax breach.
Do you have a similar opinion in regards to crimes? Do you think that there will be less crime if there are harsher prison sentences? Are you in favor of mandatory minimum sentences? If not, why do you think harsher punishments are needed here but not for crimes?
Street crimes have a far different cause and should be treated differently. I'm surprised I even have to type that, it seems obvious.
Re: OpenBSD was right to disable hyperthreading [video]
#273Earlier quoted context omitted.
Isn't this a "sane" default only in specific contexts though? (VMs). For a desktop PC that almost always runs a single heavy task (games, rendering, video encoding, etc) hyperthreading can be a day and night difference.
Yess, "sane" is context-specific, but it's useful to err on the side of more security and less performance, rather than the other way round.
It would be especially awesome if this could be enabled at runtime so it could be turned on when thing specific tasks, like rendering or compiling something big. Even better, it would be nice to lock that to specific processes (i.e. enable it on a few cores and lock privileged processes to those cores).
Re: OpenBSD was right to disable hyperthreading [video]
#274Earlier quoted context omitted.
How many other decisions made by kernel developers are you supposed to second-guess because you know better?
On your desktop? Probably none. On the image that you're pushing out to your fleet of production servers? Maybe a couple.
If you know enough to know whether up should be using HT, you can enable it yourself.
Re: OpenBSD was right to disable hyperthreading [video]
#275Earlier quoted context omitted.
I think deep down all people are communists - they all like things for free.
I disagree. Just because people like free stuff doesn't mean they want to force others (and themselves) to provide that free stuff. Some certainly do, but there are plenty who don't.
Re: OpenBSD was right to disable hyperthreading [video]
#276Earlier quoted context omitted.
It strains credulity to believe that Intel wasn't aware that they were trading side-channel resistance for performance. The problems are just too deep and pervasive. None of AMD, ARM, Power, or SPARC came close to the number and severity of issues in Intel chips. There were problems in those chips, but their nature and limited scope shows that everybody had a rough idea about how far they could go before they made pr…
> It strains credulity I don't agree. Meltdown: Intel, IBM, some ARM Spectre v1: Intel, ARM, IBM Spectre v2: Intel, ARM, IBM, AMD Spectre v3a: Intel, ARM Spectre v4: Intel, ARM, IBM, AMD L1TF: Intel, IBM Meltdown-PK: Intel Spectre-PHT: Intel, ARM, AMD Meltdown-BND: Intel, AMD MDS: Intel RIDL: Intel That doesn't look to me like "everybody had a rough idea about how far they could go." It is really easy for me to belie…
For example, Meltdown exposed severe negligence in Intel's design. For ARM Meltdown was limited to values of a single register, for which there's no reason to believe it was anything other than an unintentional bug--i.e. you don't get any substantial performance benefits from permitting speculation through that single register, though it perhaps simplified some other aspect of the chip.
Basically, if you go down the line Intel's issues were both more severe and pervasive, as-if they just didn't care about preventing speculation across privilege domains.
Notwithstanding the ARM's Meltdown mistake, both ARM and AMD very clearly had designs that attempted to prevent speculation across privilege domains. And they mostly succeed. The major issues are at syscalls where intra-privilege (not cross-privilege) speculation can indirectly be exploited by unprivileged callers. But like with SMT, it was always sort of understood that it was the operating system's responsibility here; there really are no good hardware mitigations.
Basically, the exploits for AMD and ARM (notwithstanding the lone register issue) are intrinsic to speculative execution, period. And everybody sort of understood this, especially in the cryptographic community with work on constant-time algorithms. It's just that everybody was too lazy to take it seriously more generally until Meltdown/Spectre lit a fire under everybody's pants. And once they began to pay attention, it immediately became clear that Intel's designs made patently and grossly unsafe design choices.
The details on IBM Power chips are spartan. I think their Meltdown issue was similar to ARM--a bug with a register--but I can't confirm that. My impression is that Power pushed the envelope more heavily than AMD and ARM, but not like Intel. Power went all-in on SMT, though, and though SMT is fundamentally anathema to cross-privilege confidentiality, Intel's and IBM's SMT implementations seem to leak more than AMD's.
Re: OpenBSD was right to disable hyperthreading [video]
#277Earlier quoted context omitted.
Are scripts loaded in a web browser considered "users". If so, don't most people run systems which cant trust all of their users?
No, the person using the browser that loads the scripts is the user. The user has the option to disable JavaScript, so they are responsible for whatever they allow to be run on the machine. If you don't trust yourself to use the web safely, then put limits on what a naughty script can do. One option is to disable hyperthreading.
Re: OpenBSD was right to disable hyperthreading [video]
#278Earlier quoted context omitted.
The problem with fines is that they happen after the fact and only if the worst actually happens. Tons of companies have totally abominable security and never get breached only out of dumb luck. So you'll still get lots of companies playing Russian Roulette where they make higher profits for ten years before they may or may not suffer a breach and get fined into oblivion, at which point they file for bankruptcy and s…
If you make the fine large enough that it may cause the company to go under, you can bet they'll buy some insurance. And you can bet the insurance companies will have some standards to reduce the risk of a company getting breached, such as doing audits regularly. For example, if Equifax faced a fine of $5B (more than 1/4 of their market cap) instead of $500M, you can bet they'd be more serious about audits in the fut…
It also doesn't make any sense to base fines on market cap because the two things have nothing to do with one another. All that would really do is cause corporations to restructure their operations to separate the entity that does all the dirty work from the one that owns all the assets, so that the entity that exists in your jurisdiction and is susceptible to being fined is renting/leasing everything and has only a nominal market cap, whereas the one with all the assets is a totally independent company that isn't even in your jurisdiction and never does anything "wrong" because all it ever does is lease and license things to a different entity.
It also seems kind of obvious that even if you could try to impose a fine equal to 20-30% of a company's global market cap, all that would do is cause the local entity declare bankruptcy, dissolve and abandon your jurisdiction without actually paying the fine, because that large of a fine would exceed the long-term value of operating there. Especially when there isn't any guarantee it won't happen again if they stay. For that matter it would tend to make companies not want to operate there to begin with, because it's possible to do your best and still fail, and that kind of uncertainty is precisely how you drive businesses away.
But most importantly, it still generally isn't the large tech companies who are the ones with poor security. It's the other industries, especially finance and government, that are collecting just as much data but then doing a much worse job of securing it. What does a fine mean to the DMV or OPM?
Re: OpenBSD was right to disable hyperthreading [video]
#279Earlier quoted context omitted.
actually I just took a shower and answered my question (I think) - many of the hyperthreading bugs don't breach the process divide, they use errors in hyperthreading statefulness to use a side channel to breach memory divide, and the cores share memory, whether or not who's on what core, if any one core gets compromised, you could potentially access any of the core's memory.
Close but not quite -- sibling hyperthreads (logical cores) share cache state. Physical cores do not share cache state. Different processes, threads, or VMs on sibling hyperthreads (by definition on the same physical core) can infer the other's memory state based on the cache state. If an attacker is pinned to one hyperthread, and the victim is pinned to another which isn't a sibling hyperthread, none of the spectre…
Re: OpenBSD was right to disable hyperthreading [video]
#280Earlier quoted context omitted.
I disagree. Just because people like free stuff doesn't mean they want to force others (and themselves) to provide that free stuff. Some certainly do, but there are plenty who don't.
But people are "forced" to work anyway, free stuff or not.