[HN Gopher] Downfall Attacks
___________________________________________________________________
Downfall Attacks
Author : WalterSobchak
Score : 621 points
Date : 2023-08-08 17:27 UTC (5 hours ago)
(HTM) web link (downfall.page)
(TXT) w3m dump (downfall.page)
| buildbot wrote:
| This is a huge performance hit - up to 50% it is claimed! 70% of
| modern intel processors are affected apparently as well.
| loeg wrote:
| Key context you elided: "This depends on whether Gather is in
| the critical execution path of a program."
| buildbot wrote:
| Well yes. That is the up to part.
| ablated_maquis wrote:
| Is that 50% overhead for "Gather" instructions? If that is the
| case, then if 10% of instructions are "gathers" in your
| workload then that would be 5% overall.
| loeg wrote:
| Something like that, yeah.
| samwillis wrote:
| > _some workloads_ may experience up to 50% overhead
|
| They word there are "some workloads", I suspect that
| performance hit is rare.
| jgtrosh wrote:
| My guess is that HPC systems which run applications whose
| performance strongly depends on efficient data scatter gather
| will immediately disable the mitigation.
| graton wrote:
| It is kind of like thinking that it is a huge sale at a store
| when they say "Up to 70% off". And there are like two things in
| the whole store which are 70% off.
|
| I am always suspicious of "up to" claims.
| IlliOnato wrote:
| I always translate such weasel words to their more
| straightforward equivalent. "Up to 70% off" means for me
| "Nothing in our store is discounted by more than 70%" :-)
| [deleted]
| dralley wrote:
| "Red Hat's internal performance testing of a worst-case
| microbenchmark showed a significant slowdown. However, more
| realistic applications that utilize vector gathering showed
| only low single-digit percentage slowdowns."
|
| https://access.redhat.com/solutions/7027704
|
| Performance Impact
|
| The performance impact of the microcode mitigation is limited
| to applications that use the gather instructions provided by
| Intel Advanced Vector Extensions (AVX2 and AVX-512) and the
| CLWB instruction. Actual performance impact will depend on how
| heavily an application uses those instructions. Red Hat's
| internal performance testing of a worst-case microbenchmark
| showed a significant slowdown. However, more realistic
| applications that utilize vector gathering showed only low
| single-digit percentage slowdowns.
|
| If the user decides to disable the mitigation after doing a
| thorough risk analysis (for example the system isn't multi-
| tenant and doesn't execute untrusted code), the user can
| disable the mitigation. After applying the microcode and kernel
| updates, the user can disable the mitigation by adding
| gather_data_samping=off to the kernel command
| line.Alternatively, to disable all CPU speculative execution
| mitigations, including GDS, use mitigations=off.
| baq wrote:
| > [Q] Should other processor vendors and designers be concerned?
|
| > [A] Other processors have shared SRAM memory inside the core,
| such as hardware register files and fill buffers. Manufacturers
| must design shared memory units with extra care to prevent data
| from leaking across different security domains and invest more in
| security validation and testing.
|
| Not sure what to make of this wording. Thinly veiled threat? Hint
| that other embargoes are in place?
| loeg wrote:
| It's not super revelatory given all the other Meltdown/Spectre
| bugs. I wouldn't read too much into it.
| nightpool wrote:
| AMD had a similar vulnerability recently (Zenbleed) that used
| speculative evaluation misprediction to create an effective
| "use-after-free" bug that would reveal the contents of the
| internal SIMD register file
| https://lock.cmpxchg8b.com/zenbleed.html, that might be what is
| being referenced here.
| bruce343434 wrote:
| Is there an overview page of all these processor data leak bugs
| the last 10 years? It feels like there has been an enormous surge
| in them.
| kzrdude wrote:
| On linux one can also inspect its status about this, looking at
| "lscpu" it lists known vulnerabilities and whether the current
| cpu is affected (it could be unaffected because of microcode or
| just not an affected microarch.)
| matsemann wrote:
| Here's a compilation:
| https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...
| ngneer wrote:
| I do not doubt the severity of the flaw, but most practical
| attacks end up being far more mundane. Consider SolarWinds, for
| example. No dazzling tricks needed, whatever gets the job done.
| BeeOnRope wrote:
| What I find odd is that after the initial Spectre attacks, there
| have been a long string of these attacks discovered by outside
| researchers and then patched by the chipmakers.
|
| In principle it seems like the chipmakers should hold all the
| cards when it comes to discovery: they are experts in speculative
| execution, know exactly how their chips work and have massive
| existing validation suites, simulators and internal machine-
| readable specifications for the low-level operations of these
| chips.
|
| Outside researches need to reverse all this by probing a black
| box (plus a few much-worse-than-insider sources like patents).
|
| Yet years after the initial disclosures it's still random
| individuals or groups who are discovering these? Perhaps pre-
| Spectre this attack vector wasn't even considered, but once the
| general mechanism was obvious did the chip-makers not simply set
| their biggest brains down and say "go through this with a fine-
| toothed comb looking for other Spectre attacks"?
|
| Maybe they _did_ and are well aware of all these attacks but to
| save face and performance hits they simply hold on to them hoping
| nobody makes them public?
| quickthrower2 wrote:
| My guess: There are a lot more researchers on the outside than
| inside. And also incentives - you would need a red team at
| Intel who tries to attack their own chips, and those people
| would be even fewer. And the best people may want to stay
| independent.
| TZubiri wrote:
| It's probably that they are aware of several vulnerabilities,
| such is life. But they are unable to prioritize them and assess
| which to solve first, they need external auditors using black
| box techniques to help them identify which are exploitable by
| external attackers, so they can fix that one, and not the other
| non issues
| efficax wrote:
| an easier explanation is that modern chipsets are incredibly
| complex, side channel attacks like these are hard to reason
| about and traditionally, processors themselves have not been
| the target of these kinds of attacks, so i don't think the
| engineers working on them are accustomed to thinking about them
| as attack surfaces in this way.
| DropInIn wrote:
| Tinfoil hat time:
|
| They know at release about many of these bugs but between
| incentivizing upgrades and selling the resultant bugs as
| backdoor to 'three letter agencies' there's simply too much
| money to be made by not disclosing/patching the problems before
| third parties release discovery of the problems.
| infinityio wrote:
| This could be a case of survivorship bias - we don't know how
| many spectre-like bugs _did_ get patched, because they never
| made it to the public
| api wrote:
| We also don't know how many are still out there unreported
| and part of the secret zero-day caches of various
| intelligence agencies.
| BeeOnRope wrote:
| I considered this, but we have pretty good evidence that the
| chipmakers have not been busily secretly patching Spectre
| attacks:
|
| 1) Microcode updates are visible and Spectre fixes are hard
| to hide: most have performance impacts and most require
| coordination from the kernel to enable or make effective
| (which are visible for Linux). There have been a large number
| of microcode changes tied to published attacks and
| corresponding fixes, but no corresponding "mystery" updates
| and hidden kernel fixes to my knowledge which have a similar
| shape to Spectre fixes.
|
| It's _possible_ they could wait to try to bundle these fixes
| into a microcode update that arrives for another reason, but
| the performance impacts and kernel-side changes are harder to
| hide.
|
| 2) If this were the case, we'd expect independent researches
| to be at least in part re-discovering these attacks, rather
| than finding completely new ones. This would lead to a case
| where an attack was already resolved in a release microcode
| version. To my knowledge this hasn't really happened.
| mabbo wrote:
| You don't need to patch the errors found during the initial
| R&D. The patch was made before the hardware was ever sold.
|
| What's left are the attack vectors that Intel's greatest
| minds didn't discover.
| hinkley wrote:
| Or the problem could be with methodology, and the wrong
| people are in charge of the right people left, and so the
| mindset for testing is just wrong.
|
| Also you're dealing with a company that has been running to
| stand still for a long time. There's been a lot of pressure
| to meet numbers that they simply cannot keep up with. At some
| point people cheat, unconsciously or consciously, to achieve
| the impossible.
| BeeOnRope wrote:
| > Also you're dealing with a company that has been running
| to stand still for a long time
|
| I'm not just talking about Intel, but also Arm and AMD. As
| far as I know none of these has obviously been making
| proactive Spectre fixes.
| Method-X wrote:
| Like how car companies will do a cost/benefit analysis to see
| if a recall is worth it.
| david-gpu wrote:
| Having worked in the industry, my gut feeling is that
| chipmakers don't invest all that much in looking for and
| preventing these sorts of attacks.
|
| When working on a new feature, you are desperately trying to
| deliver on time something that adds value in the sorts of
| scenarios that it was designed for. And that is already hard
| enough.
| hackermatic wrote:
| A fundamental problem is that the attack surface is so, so
| huge. Even if their security researchers are doing blue-sky
| research on both very small and very broad areas of processor
| functionality, they're going to miss a lot.
|
| And in line with that and
|
| >Maybe they _did_ and are well aware of all these attacks but
| to save face and performance hits they simply hold on to them
| hoping nobody makes them public?
|
| ... maybe they _have_ patched a number of issues and just never
| announced them.
| BeeOnRope wrote:
| > A fundamental problem is that the attack surface is so, so
| huge. Even if their security researchers are doing blue-sky
| research on both very small and very broad areas of processor
| functionality, they're going to miss a lot.
|
| Sure. If they had patched a bunch of Spectre vulnerabilities
| and independent researchers had discovered a few more that
| would be one thing, but as far as I can tell they have
| patched _zero_ while independent researches have found many
| and it has been years since the initial attack. Many of these
| follow very similar patterns and "in what cases is protected
| data exposed via speculative execution" is something that an
| architect or engineer could definitely assess.
| adgjlsfhk1 wrote:
| I think you're last statement is half right. They probably
| don't bother looking for them that hard because if they look
| for them they might find them and then have to make their CPUs
| slower before launch.
| [deleted]
| z3t4 wrote:
| You are describing a creator bias, there are probably a better
| name, where you think the ones who created something knows it
| best. For example, you could create a programming language, a
| game, or anything, and you think that you know it better then
| someone who use it for several hours every day. The larger the
| user base the less likely you are better or know it better then
| all users.
| CTDOCodebases wrote:
| And maybe just maybe when the Snowden revelations started to
| come out some people woke up and realised that the companies
| who design the processors used in the vast majority of
| computers are from the US.
|
| https://www.theverge.com/2013/12/20/5231006/nsa-paid-10-mill...
| bsder wrote:
| The problem is that nobody wants to admit that the old, stodgy
| mainframe guys were right 30 years ago and that sharing
| _anything_ always results in an exfiltration surface.
|
| Nobody wants to be the first to take proper steps because they
| have to either:
|
| 1) Partition hardware properly so that users are genuinely
| isolated. This costs silicon area that nobody wants to pay for.
|
| 2) Stop all the speculative bullshit. This throws performance
| into rewind and will put chip performance back a decade or two
| that nobody wants to pay for.
|
| Until people are willing to value security enough to put real
| money behind it, this will continue ad nauseam.
| tracker1 wrote:
| I'd add that the status quo has done pretty well, and many of
| these exploits are fixed. It's also worth noting that a lot
| of the exploits in question may be known, but the people
| working on them couldn't theorize a practical exploit. How
| many web browser sandbox breaches have there been over the
| years? Far less than the CPU exploits in the past several
| years. The latter can have a much bigger impact though.
|
| The biggest risk target seems to be shared servers, and you
| often don't _know_ who you 're sharing with, so is it worth
| trying? It seems to be usually, no... in a specific target,
| maybe.
| zamadatix wrote:
| The logic in this comment rubs me the wrong way. You could use
| the same train of thought to postulate programmers that have
| made 2 memory safety errors are nefarious instead of simply
| human.
|
| When billions use something I expect them to find more
| problems, flaws, and exploits in it than the
| creator/manufacturer did. The presence of this does nothing to
| indicate (or refute) any further conclusion about why.
| BeeOnRope wrote:
| I think the comparison between CPU and software exploits
| holds at a very high level, but in the case of software the
| gap between internal and external researches seems lower.
| Much software is open-source, in which case the play field is
| almost level and even closed source software is available in
| assembly which exposes the entire attack surface in a
| reasonably consumable form.
|
| Software reverse-engineering is a hugely popular, fairly
| accessible field with good tools. Hardware not so much.
|
| > When billions use something I expect them to find more
| problems, flaws, and exploits in it than the
| creator/manufacturer did. The presence of this does nothing
| to indicate (or refute) any further conclusion about why.
|
| To be very clear none of these errors have been found by
| billions of random users but by a few interested third
| parties: many of them working as students with microscopic
| funding levels and no apparent inside information.
|
| I'm not actually suggesting that the nefarious explanation
| holds: I'm genuinely curious.
| justinator wrote:
| _> In principle it seems like the chipmakers should hold all
| the cards when it comes to discovery: they are experts in
| speculative execution, know exactly how their chips work and
| have massive existing validation suites, simulators and
| internal machine-readable specifications for the low-level
| operations of these chips._
|
| I hope you're not in charge of hiring QA. Bugs are often found
| by people who AREN'T thinking like the developers whichstart
| wearing blinders on how they're stuff should work and stop
| trying stupid things.
| margalabargala wrote:
| > I hope you're not in charge of hiring QA.
|
| This seems unnecessarily harsh. The whole post would be
| improved by removing that sentence IMO.
| justinator wrote:
| I'm in the camp that developers shouldn't be responsible
| for having a transcendental ability to predict future
| (example) security holes. If one appears, it's really the
| QA's job to document it and experiment with other similar
| vectors of attack. The developers are, you know:
| developing. Bring them back in when the security issues
| needs to be fixed, once it's found just how big the problem
| is.
| BeeOnRope wrote:
| I'm not directly in charge of hiring QA, no!
|
| I think this sort of excuses the initial blindness to Spectre
| style attacks in the first place, but once the basic pattern
| was clear it doesn't excuse the subsequent lack of
| discovering any of the subsequent issues.
|
| It is as if someone found a bug by examining the assembly
| language of your process which was caused by unsafe inlined
| `strcpy` calls (though they could not see the source, so they
| had no idea strcpy was the problem), and then over a the
| subsequent 6 years other people slowly found more strcpy
| issues in your application using brute-force black-box
| engineering and meanwhile you never just grepped your
| (closed) source for strcpy uses and audited them or used many
| of the compiler or runtime mitigations against this issue.
| justinator wrote:
| That still seems like a job for QA and you do have a good
| point. If there's an attack using one technique, there
| should be an audit to make sure that technique can't be
| modified to be used in other nasty ways, then have those
| tests part of the test suite.
| errantmind wrote:
| The Linux mitigation can be disabled with
| gather_data_sampling=off in the kernel boot parameters.
|
| Be warned, apparently Grub had some kind of problem back in
| August 2022 and this pre-existing bug broke my boot completely
| when I updated grub for the above mitigation. I had to boot into
| a live ISO and reinstall grub to fix it.
| Lt_Riza_Hawkeye wrote:
| Simply removing the parameter didn't fix it? Or you just
| reinstalled grub to be sure it would work
| errantmind wrote:
| The parameter was unrelated to the issue with grub but I
| thought I'd mention the grub issue in case anyone else gets
| surprised like me.
| GartzenDeHaes wrote:
| How could an attacker gain the level of knowledge necessary to
| accomplish this without compromising the target process?
| dwrodri wrote:
| I've only done a quick read through the link, but I think the
| model they imply is that a malicious user could rent a Cloud VM
| in AWS/Azure/GCP/etc and then sniff the contents of SIMD
| registers, similar to the Zenbleed attack which was also
| disclosed recently[1]. This is a big deal because optimized
| implementations of strcpy, strlen, and memcpy in glibc all use
| SIMD registers, and glibc is everywhere.
|
| 1: https://lock.cmpxchg8b.com/zenbleed.html
| GartzenDeHaes wrote:
| How do they know what data is in the registers? In the linked
| article, the person running the attack code knows what is
| running on the target. The target is also conveniently
| waiting for the attack code to run without doing anything
| other than referencing the target data.
| ancris wrote:
| At this rate, with all these vulnerabilities and mitigations,
| we'll rollback CPU performance back at least 10 years.
| IlliOnato wrote:
| The only 100% reliable way is to turn off branch prediction
| completely, and yes, this would make the processors at least 2
| times slower, perhaps more.
|
| Too bad that apparently nothing came out of the Mill
| architecture. My limited understanding is that this
| architecture would not have such vulnerabilities.
|
| Of course it's possible it would have others :-) but being much
| simpler, at least conceptually, perhaps it would have less and
| easier to mitigate. Oh well.
| javajosh wrote:
| Yep it's almost like Moore's Law in reverse.
| Aaronmacaron wrote:
| Are there any known attacks which exploited Spectre or Meltdown
| vulnerabilities? And is it likely that this vulnerability will be
| successfully used to perform attacks?
| [deleted]
| throwaway892238 wrote:
| This is one of many similar previous attacks, and more of these
| attacks will continue to come out and be increasingly weaponized.
| From now on the assumption must be that same-core computing is
| not secure.
| xyst wrote:
| So it seems like speculative execution cannot be disabled. What's
| the mitigation here? Nothing and wait for patch or significant
| redesign?
| snvzz wrote:
| >What's the mitigation here?
|
| Replace the buggy CISC CPU. Ideally with a less complex thus
| highly likely less buggy RISC one.
| samwillis wrote:
| Ouch, I wander if they received a bug bounty from Intel for
| this...
| snvzz wrote:
| ISA complexity breeds microarchitecture bugs.
|
| In the internet era, x86 is an anachronism.
|
| RISC is the way forward.
|
| RISC-V is inevitable.
| thewataccount wrote:
| Does anyone know what type of workloads this effects the
| performance of the most? Is this specialty-type of workloads or
| are general webserver/database/coding/compiling/gaming/desktop
| usages effected?
| ndesaulniers wrote:
| Intel Security Advisory:
| https://www.intel.com/content/www/us/en/developer/articles/t...
|
| Linux Kernel merge:
| https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
| aestetix wrote:
| I just did a cursory readthrough. Am I correct to think this
| feels a bit like heartbleed, but for CPU registers rather than
| memory?
| Dalewyn wrote:
| Am I correct in understanding this affects basically every CPU
| generation up to and including Alder Lake?
|
| EDIT: Maybe not? That linked table is very esoteric.
| mike_hearn wrote:
| The Intel paper link is dead, this seems to be the right one:
|
| https://www.intel.com/content/www/us/en/developer/articles/t...
|
| General caveats: are there many clouds that still run workloads
| from different users on the same physical core? I thought most
| had changed their schedulers years ago so you can't get cross-
| domain leaks between hyperthreads anymore. Claiming that it
| affects all users on the internet seems like a massive over-
| exaggeration, as he hasn't demonstrated any kind of browser based
| exploit and even if such a thing did exist, it'd affect only a
| tiny minority of targeted users, as AFAIK many years after the
| introduction of Spectre nobody has ever found a specex attack in
| the wild (or have they?)
|
| I think the more interesting thing here is that it continues the
| long run of speculation bugs that always seem to be patchable in
| microcode. When this stuff first appeared there was the looming
| fear that we'd have to be regularly junking and replacing the
| physical chips en masse, but has that ever been necessary? AFAIK
| all of the bugs could be addressed via a mix of software and
| microcode changes, sometimes at the cost of some performance in
| some cases. But there's never been a bug that needed new physical
| silicon (except for the early versions of AMD SEV, which were
| genuinely jailbroken in unpatchable ways).
| tedunangst wrote:
| Does Digital Ocean count as a major cloud player?
| winternewt wrote:
| The Spectre attack had to be patched in the kernel in a way
| that significantly slowed down execution on Intel CPU:s:
| https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
| mike_hearn wrote:
| Yes, I think that's what I said? Every attack no matter how
| deep it seemed to be has been patchable in microcode,
| sometimes at a cost in performance. But so far nobody had to
| toss the physical silicon, at least not with Intel. The
| malleability of these chips is quite fascinating.
| rocqua wrote:
| The meltdown and spectre mitigations weren't patched in
| microcode, they were patched by changing the internal
| calling methods of the kernel.
| mike_hearn wrote:
| I think it was both. There were initial software only
| patches, but those were quickly superseded by
| microcode+kernel patches, where microcode added features
| the kernel enabled. IBRS or something like that.
| cbsmith wrote:
| It was both, and none of them completely addressed the
| problem. They did need new hardware for that.
| calibas wrote:
| > Claiming that it affects all users on the internet seems like
| a massive over-exaggeration, as he hasn't demonstrated any kind
| of browser based exploit and even if such a thing did exist
|
| He's saying it likely affects "everyone on the Internet"
| because most servers are vulnerable.
| Dylan16807 wrote:
| Most servers being vulnerable to a local attack is generally
| pretty boring news.
| kiririn wrote:
| >are there many clouds that still run workloads from different
| users on the same physical core?
|
| There are a vast number of VPS providers out there that aren't
| AWS/GCP/Azure/etc where the answer is yes. Even the ones that
| sell 'dedicated' cores, which really just means unmetered cpu
| H8crilA wrote:
| What about burstable instances on AWS, and whatever is the
| equivalent in other clouds? Hard to imagine those having a
| dedicated core, would probably defeat the purpose.
| watermelon0 wrote:
| Not just burstable instances.
|
| AWS Fargate, container as a service, allows specifying 0.25
| or 0.5 CPU, and I would be surprised if those weren't
| shared.
|
| Same probably? also applies to AWS Lambda.
| tracker1 wrote:
| My guess is there's likely less value in trying to target
| those kinds of environments... Just poking random data
| out of lambda or low end vps neighbors is a needle in a
| haystack the size of the moon in terms of finding
| anything useful.
|
| It's more likely useful as part of a group of exploits to
| hit an individual, targeted system.
| c2h5oh wrote:
| Worse: by default it's not CPU but VCPU - a single core
| with multithreading = 2 VCPU
| schlarpc wrote:
| https://docs.aws.amazon.com/whitepapers/latest/security-
| desi....
| ajross wrote:
| Per the paper, this looks like an attack against speculated
| instructions that modify the store forward buffer. The
| details aren't super clear, but that seems extremely unlikely
| to survive a context switch. In practice this is probably
| only an attack against hyperthread code running
| simultaneously on the same CPU, which I'd expect cloud hosts
| to have eliminated long ago.
| amarshall wrote:
| > same physical core...between hyperthreads
|
| These are not the same thing. Afaik, most "vCPU" are
| hyperthreads, not physical cores.
|
| > I thought most had changed their schedulers years ago so you
| can't get cross-domain leaks between hyperthreads anymore
|
| It would be great to have a source on this.
| BeeOnRope wrote:
| > These are not the same thing. Afaik, most "vCPU" are
| hyperthreads, not physical cores.
|
| OP didn't say otherwise. They are saying that public clouds
| do not let work from different tenants run on the _same_
| physical core (on _different_ hyperthreads) _at the same
| time_.
|
| This doesn't prevent you from selling 1 hyperthread as 1
| vCPU, it just means there are some scheduling restrictions
| and your smallest instance type will probably have 2 vCPUs if
| you have SMT-2 hardware (and that's exactly what you see on
| AWS outside of the burstable instance types).
| vladvasiliu wrote:
| > General caveats: are there many clouds that still run
| workloads from different users on the same physical core? I
| thought most had changed their schedulers years ago so you
| can't get cross-domain leaks between hyperthreads anymore.
|
| Isn't this the whole point of AWS' t instances? It's my
| understanding that they are "shared" at the core level, or else
| there wouldn't be a reason for the CPU credit balance thing.
| BeeOnRope wrote:
| They are definitely time-sliced among tenants and very
| possibly two tenants may run at the same time on two hardware
| threads on the same core: but you could have a viable
| burstable instance with time-slicing alone.
| BeeOnRope wrote:
| Nevermind, AWS explicitly documents that all instance
| types, including burstable, never co-locate different
| tenants on the same physical core at the same time:
|
| https://docs.aws.amazon.com/whitepapers/latest/security-
| desi...
| pwarner wrote:
| I think most if not all cloud VMs dedicate a core to you. Well,
| there are some that share like the T series on AWS and I think
| other clouds have similar, but my bet is they can put in an
| extra "flush" between users to prevent cross tenant leakage.
|
| Of course cross process leakage for a single tenant is an
| issue, in cloud or on prem, and folks will have to decide how
| much they trust the processes on their machine to not become
| evil...
| basedrum wrote:
| Can someone explain why the ssh video at 2:25, where the 256bit
| comparison is pasted in, it doesn't match? The first two colon
| separated number sets do match, but not the following two?
| Veserv wrote:
| I am a little unclear on the attack. What data in the temporal
| buffer is being forwarded to the attacking vpgather?
|
| Is the content of the temporal buffer just being blindly
| forwarded during speculative execution even if the indexed
| address of the attacking vpgather does not match?
|
| Otherwise how is the speculative vpgather allowed to load the
| values of the temporal buffer?
|
| If it is not blind is it a virtual address match? I guess it
| could also be a not-Present mapping physical match as well? I can
| not think of any other possibility off the top of my head.
|
| If it is a blind forward that is pretty amazingly bad.
| Negitivefrags wrote:
| Once again it seems clear that running code from two security
| domains on the same physical processor cores is just not possible
| to get right, and we should probably just stop doing it.
|
| There are really only two common cases for this anyway. VMs and
| JavaScript.
|
| For VMs we just need to give up on it. Dedicate specific cores to
| specific VMs or at least customers.
|
| For JavaScript it's a bit harder.
|
| Either way, we need to not be giving up performance for the the
| normal case.
| [deleted]
| paxys wrote:
| So one should never install software from more than one company
| on a computer?
| accrual wrote:
| > Once again it seems clear that running code from two security
| domains on the same physical processor cores is just not
| possible to get right, and we should probably just stop doing
| it.
|
| I believe this is why OpenBSD disabled SMT by default in June
| of 2018. [0]
|
| It can still be enabled with a simple 'sysctl', though.
|
| [0] https://www.mail-archive.com/source-
| changes@openbsd.org/msg9...
| hyperman1 wrote:
| I've wondered if we can't give a dedicated core to the browser.
| Of course, then web pages can steal from other web pages. Maybe
| task switching needs to erect much higher barriers between
| security contexts, a complete flush or so?
| moonchild wrote:
| You would need a dedicated core per _tab_.
|
| Partitioning tabs according to trust would be ~fine, but
| laborious and error-prone.
| Negitivefrags wrote:
| It probably would be possible to add a new instruction that
| causes the processor to flush all state in exchange for
| sacrificing task switching speed. Of course it might still
| have bugs, but you could imagine that it would be easier to
| get right.
|
| Of course, it's not doing much for the billions of devices
| that exist.
|
| I would hope that we could find a software solution that web
| browsers can implement so that devices can be patched.
|
| Either way, I would want such a solution to not compromise
| performance in the case where code is running in the same
| security context.
|
| This is what I don't like about existing mitigations. It's
| making computers slower in many contexts where they don't
| need to be.
| zamadatix wrote:
| Software can choose to invalidate all cache, fence access,
| and the like today. It may not be a single instruction but
| it's not far off. Usually something like "just don't JIT
| 3rd party JS to native code" is "secure enough" most don't
| want to go down that route though. For cloud (reputable)
| providers just don't allow more than 1 VM to be assigned to
| a core at the same time and flush everything between if
| they are time shared. The mitigations are the way to keep
| the most overall performance outside those who are most
| concerned with maximum security, so they are the most
| popular.
| bee_rider wrote:
| I wish chips would come with a core devoted to running this
| kind of untrusted code; maybe they could take something like
| an old bonnell atom core, strip out the hyper threading, and
| run JavaScript on that.
|
| If a script can't run happily on a core like that, it should
| really be a program anyway, and I don't want to run it.
| hsbauauvhabzb wrote:
| I'm not saying you're wrong, but I have a hard time
| believing web developers would be capable of writing code
| efficient enough to share a single core. LinkedIn was
| slamming my CPU so much that I isolated it in a separate
| browser
| bee_rider wrote:
| I think you are right, my wish involves living in a
| slightly different universe where the web has taken a
| slightly less silly direction of development.
| bhk wrote:
| Once you "dedicate cores to specific VMs" you will find that
| chip designers can also screw that up, just like they can screw
| up protection within a core. So you might as well proclaim that
| "impossible to get right" preemptively.
| quickthrower2 wrote:
| They said physical processor. I took this to mean chip. Of
| course you can't trust chips on the same mother board (there
| could be a bug where they can read the same memory), so you
| need a network boundary. So different rack on the server, for
| each [boundary, however you define that...]
| kazinator wrote:
| > _Once again it seems clear that running code from two
| security domains on the same physical processor cores is just
| not possible to get right, and we should probably just stop
| doing it._
|
| Yes. This has had its heyday: the era of the time-shared
| systems, from the 1960's, right into the 1990's (Unix systems
| with multiple users having "shell accounts", at universities
| and ISP's and such). These CPU attacks show us that secure
| time-shared systems where users run arbitrary machine code is
| no longer feasible.
|
| There will still be time sharing where users trust each other,
| like workers on the same projects accessing a build machine and
| whatnot.
| bee_rider wrote:
| It is sort of like the second law of thermodynamics (before
| statistical mechanics came around and cleared things up): sure,
| maybe not well founded in some analytical or philosophical
| sense, but experimentally bulletproof to the point where anyone
| who tries to sell you otherwise would be regarded very
| suspiciously. The idea that any two programs running on a
| computer can be prevented from snooping on each other.
| hinkley wrote:
| This seems like a job for Arm or RISC-V or ???
|
| Sacrifice IPC/core to reduce gates per core, stuff more cores
| into a square centimeter, pin processes to cores or groups of
| cores, keep thread preemption cheap, but let thread migration
| take as long as it takes.
|
| Arm already has asymmetric multiprocessing, which I feel like
| is halfway there. Or maybe a third. Fifteen years ago
| asynchrony primitives weren't what they are today. I think
| there's more flexibility to design a core around current or
| emerging primitives instead of the old ways. And then there are
| kernel primitives like io_uring meant to reduce system call
| overhead, amortizing over multiple calls. If you split the
| difference, you could afford to allow individual calls to get
| several times more expensive, while juggling five or ten at
| once for the cost of two.
| marssaxman wrote:
| > For JavaScript it's a bit harder.
|
| "We should probably just stop doing it" works for me.
| throwaway892238 wrote:
| Agreed. Browsers are now nothing but an application platform
| of APIs (https://developer.mozilla.org/en-US/docs/Web/API).
| For some reason they still retain the vestigial HTML, CSS and
| JS, but really all you need is bytecode that calls an ABI,
| and a widget toolkit that talks to a rendering API. Then we
| can finally ship apps to users without the shackles of how a
| browser wants to interpret and render some markup.
|
| The idea of security "sandboxes" is quaint, but have been
| defeated pretty much since their inception. And the only
| reason we have "frontend developers" rather than just
| "developers" is HTML/CSS/JS/DOM/etc is a byzantine relic we
| refuse to let go of. Just let us deliver regular-old apps to
| users and control how they're displayed in regular
| programming languages. Let users can find any app in any
| online marketplace based on open standards.
| xigency wrote:
| I do think there's never been a better time to reinvent the
| web, including basic technologies like HTML and JavaScript.
|
| For example, picking up more elements of semantic web and
| distributed systems and leveraging interconnected devices.
| sidewndr46 wrote:
| If someone created a way for WASM to talk to an SDL
| equivalent, it'd probably end use of HTML & CSS
| yvdriess wrote:
| And so closing the great circle of UI framework
| technologies.
| wg0 wrote:
| IF GTK/Qt etc can render to canvas using WebGPU while
| compiled to assembly, I think game is almost over than
| too IF there's a way to lazy load application modules.
|
| Think Autodesk products. Certain parts (wasm modules)
| only load when you hover over a menu while overall app
| loads within milliseconds because it just has the main
| window and such.
| throwaway12245 wrote:
| WASM has support for SDL for a long time:
| https://www.jamesfmackenzie.com/2019/12/01/webassembly-
| graph...
| t0astbread wrote:
| If tri-state logic becomes viable it's game over for
| binary!
| tomsmeding wrote:
| If so, all people relying on (often limited even with
| html that contains text) accessibility features will have
| to sit in a corner and cry.
| wg0 wrote:
| I think that should be addressable.
| jl6 wrote:
| There's a marketing opportunity here to put multi-core back in
| the spotlight. Most workloads have reached the point of
| diminishing returns for adding more cores to a CPU, but if it
| turns out we need more cores just so we can run more concurrent
| processes (or browser tabs) securely, then here come the
| 128-core laptop chips...
| malfist wrote:
| This is an unreasonable position. Vulnerabilities can be fixed
| layer8 wrote:
| You are assuming that white hats discover them early enough
| before black hats.
| 2OEH8eoCRo0 wrote:
| The mitigation here can incur a whopping 50% performance
| penalty. At what point can customers return these CPUs for
| either being defective or sue for false advertising? If they
| can't safely meet the target performance they shouldn't be
| doing these tricks at all.
| dcow wrote:
| Did processor companies _ever advertise_ that processors
| guaranteed certain security properties of the software they
| execute?
|
| Aren't system designers at fault for coming up with the
| idea of a context switch and _assuming_ that we can trust a
| processor not to leak details across artificial software
| constructed boundaries?
| 3np wrote:
| According to OP, SGX is also vulnerable. There has been
| quite some marketing around the supposed security
| properties of SGX, yes.
| rvnx wrote:
| But wait, how is it even considered a processor bug ?
|
| You write data inside the registers, yes, other processes
| can read these registers.
|
| It always been like this, and is absolutely normal.
|
| It's the responsibility of the operating system to clear
| the registers if it is switching context.
| duped wrote:
| > But wait, how is it even considered a processor bug ?
|
| These side channel attacks allow an attacker to read
| registers from other processes before any context
| switching has occurred, or independently of any context
| switching (even if the OS has been written to correctly
| clear state).
| [deleted]
| IlliOnato wrote:
| Yeah, I am sure the customers can sue, but would they
| win? I find it unlikely.
| jjav wrote:
| > This is an unreasonable position. Vulnerabilities can be
| fixed
|
| That's a highly optimistic position, to the point of being
| almost wishful thinking.
|
| The vulnerability being talked about today has been around
| since 2014 according to the report. Possibly being exploited
| for unknown number of years since. Sure, maybe we can
| workaround this one, now.
|
| Other similar ones to be published years into the future are
| also there today being likely exploited as we speak.
|
| Running untrusted code on the same silicon as sensitive code
| (data), is unlikely to ever actually be truly safe.
| alerighi wrote:
| The real problem here is the x86 architecture. We should
| stop using it. It's too complex, it's full of stuff made
| for backward compatibility purposes, it has too many
| instructions that may have unpredictable results, and for
| that exact reason it's extremely difficult to get things
| right. Somewhere in the thousands of instructions that it
| has you will surely find a bug.
|
| We should move forward. Apple did a great job with the
| M{1,2} processors. Not only they are fantastic in terms of
| performance and energy usage, but also (to this moment)
| they don't seem to suffer from these issues. The reason is
| that the CPU is simpler, and a simpler thing is easy to
| design right in the first place.
| hinkley wrote:
| Vulnerabilities are like unreliable cars. It doesn't matter
| so much if they can be fixed, it's the very, very high
| opportunity cost of needing to be fixed, when you were busy
| doing something else of high value.
|
| Responsible people tend to pick the small consequence now
| over the unknowable distribution of consequences later.
| pseudalopex wrote:
| > Vulnerabilities can be fixed
|
| Not always the damage.
| tomrod wrote:
| Geez! This seems like a _really_ big attack vector. Anyone on the
| security side have some caveats?
| Chabsff wrote:
| If I'm reading this right, the caveat is that the exploit only
| lets you read registers that have been saved for context-
| switching.
|
| So, in order to extract data, that data must be in constant
| active use (i.e. loaded in a register) at the time of the
| attack.
| Veserv wrote:
| It claims to also allow you to read any data loaded into a
| vector register, any data loaded from a {rep mov} (i.e.
| memcpy), any data used by crypto acceleration, and a bunch
| more. Basically, the only data it does not let you read is
| regular loads into the regular GPRs (i.e. what would be a
| register load in a RISC architecture) though if you
| save/restore during context switches using the special
| instructions you will leak the values at the time of the
| context switch.
|
| This is about as close to a total cross-process data leak as
| can be imagined.
| tomrod wrote:
| Would environmental variables be something that shows up in
| context-switching?
| loeg wrote:
| Typically not, but only because they are not typically
| accessed frequently.
| ZephyrP wrote:
| In general, not really, but the most common string
| comparison instruction in x86_64 leaves the last character
| of _one_ of the strings being compared with the other one
| just being a pointer into the C-style string.
| [deleted]
| stalfosknight wrote:
| I'm getting annoyed with all of these yawning security holes in
| Intel's CPUs. I'm tempted to replace my Intel MacBook Pro with an
| Apple Silicon model sooner than I normally would.
| darkclouds wrote:
| Its the trade off for performance.
| SoftTalker wrote:
| I'm not sure what evidence there is to think that Apple's chips
| are any better. And that's not really a dig at Apple; these are
| just very complicated devices and especially with the
| optimizations that CPUs need to make to run today's software
| with acceptable performance, it can become very hard to foresee
| all possible attacks and vulnerabilities.
| stalfosknight wrote:
| I'm not trying to suggest that Apple's ARM chips are
| magically better because they're designed by Apple. Rather
| that the x86 architecture is obviously very long in the tooth
| and now would be a great time to switch to a far more modern
| architecture especially in light of this steady stream of
| vulnerabilities and defects that keep being found in x86.
|
| I'm sure ARM64 isn't perfect but I've yet to learn of
| something as severe as this, or Spectre, or Meltdown.
| Remnant44 wrote:
| Almost all of these exploits are due to the out-of-
| order/speculative execution.. which is incredibly
| complicated. There is no reason to believe that an out of
| order architecture that has not been hardened is any better
| at defense here than x86 - Just that as a minority
| architecture, it's still less profitable to target for
| exploitation. I have very little faith that the Apple ARM
| chips do better here without extensive exploit attempts
| made...
| [deleted]
| coder543 wrote:
| Just as a couple of examples...
|
| ARM has suffered from Spectre too:
| https://developer.arm.com/Arm%20Security%20Center/Spectre-
| BH...
|
| There was also PACMAN:
| https://appleinsider.com/articles/22/06/10/new-pacman-
| flaw-i...
|
| Speculative vulnerabilities have virtually nothing to do
| with the instruction set. Changing the language of the
| processor has little to do with how the processor works
| under the hood, especially for fundamental technologies
| like speculative execution.
|
| Also, as a corollary, speaking the same language doesn't
| mean every vulnerability is shared. AMD does not seem
| affected by Downfall, for instance.
| stalfosknight wrote:
| I did not know about PACMAN!
| tedunangst wrote:
| Today you get to learn that there were ARM CPUs affected by
| Meltdown as well, including those sold by Apple.
| alerighi wrote:
| x86 architecture is now proven to be a minefield. It has too
| many instructions, being a CISC instruction set (something
| that was obsolete in the 90s but was keept for backward
| compatibility with older software). This means that to make
| efficient CPU the manufacturer has to do a ton of
| optimizations. These optimizations have resulted in most of
| the bugs we have seen.
|
| Contrary ARM or other RISC instruction set are more simple.
| Being more simple they rely on compilers being more smart to
| generate optimized programs (something we have to this day).
| For this processors are more simple and straight forward,
| they don't need all the complexity of an x86 CPU. For this
| reason they are also more efficient since they don't waste
| resources doing useless operations.
|
| Of course vulnerabilities can be everywhere (there were a few
| also on M1, tough not as impressive like these one, they were
| mostly stuff nearly impossible to exploit|). But recent times
| proved that particularly on x86 chips this is a real issue.
| rincebrain wrote:
| Yes, it's definitely only Intel who has these problems. [1] [2]
|
| [1] - https://lock.cmpxchg8b.com/zenbleed.html
|
| [2] - https://comsec.ethz.ch/research/microarch/inception/
| stalfosknight wrote:
| I don't own any AMD products but your point is well taken.
| galacticaactual wrote:
| Stop. Releasing. Attack research. Without. Detection strategies.
| thewataccount wrote:
| That doesn't make any sense. You want to prep a fix for
| distribution ASAP, and release it so people can be protected
| from it as soon as possible.
|
| Also many attacks are not really feasible to detect if it's
| happened - that's like trying to know if the mailman read your
| postcard.
|
| You can develop executable scanning techniques, but people are
| a lot more concerned about preventing it in the first place
| than catching it in the act. Why would you leave people
| vulnerable so they can watch data get stolen - instead of just
| fixing the issue?
| loeg wrote:
| Stop inserting random punctuation for emphasis! Periods go at
| the end of a full sentence.
| lokar wrote:
| Not all systems are equally exposed, and while there is no
| universal low level fix many systems can be redesigned at a
| higher level to reduce exposure.
| hackermatic wrote:
| They probably concluded it wasn't possible in this case. From
| their FAQ:
|
| [Q] Is there a way to detect Downfall attacks?
|
| [A] It is not easy. Downfall execution looks mostly like benign
| applications. Theoretically, one could develop a detection
| system that uses hardware performance counters to detect
| abnormal behaviors like exessive cache misses. However, off-
| the-shelf Antivirus software cannot detect this attack.
| theandrewbailey wrote:
| The detection strategy is: are you using the affected hardware?
| dralley wrote:
| It was reported to Intel a full year ago, apparently.
| bironran wrote:
| Worth to note that GCP has this patched
| (https://cloud.google.com/support/bulletins#gcp-2023-024)
| palcu wrote:
| My adjacent teams in London who work in SRE on Google Cloud
| (GCE) got some well deserved doughnuts today for rolling out
| the patches on time.
| tamimio wrote:
| So my CPU from 2015 (CPUID 306C3)
|
| - Is not affected
|
| - Doesn't support Win11
|
| And both are good to know.
| kzrdude wrote:
| See this LWN story: https://lwn.net/Articles/940783/
|
| on Linux, any cpus that don't have updated microcode will have
| AVX completely disabled as a mitigation for this issue. That's
| rather harsh if you ask me and would be very noticeable. Now I'm
| interested in finding out if I can get updated microcode..
| EGreg wrote:
| How can the registers still hold this info when users switch? I
| would think that it is very transitory, and wiped by other stuff
| quickly
| v8xi wrote:
| From FAQ: [Q] How long have users been exposed to this
| vulnerability? [A] At least nine years. The affected processors
| have been around since 2014.
|
| Amazing how these vulnerabilities sit around unnoticed for years
| and then it takes two weeks for someone to code up an exploit.
| Liquix wrote:
| All a publication indicates is that a white/grey hat researcher
| has discovered the vulnerability. There is no way to know if or
| how many times the same flaw has been exploited by less
| scrupulous parties in the interim.
| mrob wrote:
| And information leak exploits are less likely to be detected
| than arbitrary code execution. If somebody is exploiting a
| buffer overflow, they need to get it exactly right, or
| they'll probably crash the process, which can be logged and
| noticed. The only sign of somebody attempting Downfall or
| similar attacks is increased CPU use, which has many benign
| causes.
| ibejoeb wrote:
| Since it is in a class of other well known vulnerabilities,
| I'm going to assume that there has been quite a bit of active
| research by state-operated and state-sponsored labs. I think
| it's more likely than not that this has been exploited.
| xyst wrote:
| Likely work based off of previous exploits.
| robotnikman wrote:
| I have a feeling the time spent searching for the vulnerability
| in the first place was more than 2 weeks though.
| H8crilA wrote:
| Those things come in waves. Once the first large CPU
| vulnerability was found then more followed soon. I think it's
| obvious why this is so.
| [deleted]
| nwmcsween wrote:
| Haven't RTFA but would zeroing registers fix this (-mzero-caller-
| saved-regs=used)?
| pornel wrote:
| In modern CPUs registers are a high-level abstract concept (see
| register renaming), so writing to a register doesn't have any
| specific location to overwrite.
|
| Recent Zenbleed vulnerability was an example of that --
| clearing of a register was setting a temporary boolean saying
| it's zeroed instead of writing actual zeros.
| Findecanor wrote:
| I don't think so. This vulnerability is leaking data from a
| load-buffer, not directly from registers. It affects data that
| is loaded in bulk or to vector registers.
|
| However, general purpose registers are also loaded passing
| through this buffer during context switches.
| lefuturiste wrote:
| As I see, there is no debian security release yet?
| zerocrates wrote:
| Only up to 11th gen... it didn't seem like this could have been
| disclosed to Intel soon enough for them to have fixed it for 12th
| gen, so had they just happened to fix it while fixing something
| else, or what?
|
| Decided to look in the paper and "Intel states that newer CPUs
| such as Alder Lake, Raptor Lake, and Sapphire Rapids are
| unaffected, although not a security consideration and seems just
| a side effect of a significantly modified architecture." So
| basically they just randomly fixed it, or at least made this
| particular exploit nonworkable.
| [deleted]
| yakkityyak wrote:
| Not again!
| coding123 wrote:
| I guess 1995 is calling when computers were expensive.
___________________________________________________________________
(page generated 2023-08-08 23:00 UTC)