19 ms·
Downfall Attacks
- basedrum 3y agoCan 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?
- stordoff 3y agoAt the end of this video? https://downfall.page/media/gds_aes.mp4 https://downfall.page/media/gds_aes.mp4 They appear to match to me, albeit with the last few characters hidden by the timer. They are visible when the key is copied though.
- basedrum 3y agoYou are right, its the timer that threw me off.
- buildbot 3y agoThis is a huge performance hit - up to 50% it is claimed! 70% of modern intel processors are affected apparently as well.
- samwillis 3y ago> some workloads may experience up to 50% overhead They word there are "some workloads", I suspect that performance hit is rare.
- jgtrosh 3y agoMy guess is that HPC systems which run applications whose performance strongly depends on efficient data scatter gather will immediately disable the mitigation.
- loeg 3y agoKey context you elided: "This depends on whether Gather is in the critical execution path of a program."
- buildbot 3y agoWell yes. That is the up to part.
- ablated_maquis 3y agoIs 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 3y agoSomething like that, yeah.
- dralley 3y ago"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 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.
- graton 3y agoIt 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 3y agoI 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 3y ago[deleted]
- tomrod 3y agoGeez! This seems like a _really_ big attack vector. Anyone on the security side have some caveats?
- Chabsff 3y agoIf 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.
- tomrod 3y agoWould environmental variables be something that shows up in context-switching?
- deleted 3y ago[deleted]
- loeg 3y agoTypically not, but only because they are not typically accessed frequently.
- ZephyrP 3y agoIn 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.
- CanaryLayout 3y agoI think you're asking this question because you're wondering if a container that uses environment variables for its configs would show up in this and I think the answer would be no because it's an operating system service that supplies the answers for the values, but every developer on Earth copies the values into variables where there is going to be a pointer put on a register at some point which then would make it vulnerable
- 3y ago
- v8xi 3y agoFrom 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.
- robotnikman 3y agoI have a feeling the time spent searching for the vulnerability in the first place was more than 2 weeks though.
- H8crilA 3y agoThose 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.
- Liquix 3y agoAll 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 3y agoAnd 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 3y agoSince 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.
- 3y ago
- samwillis 3y agoOuch, I wander if they received a bug bounty from Intel for this...
- stalfosknight 3y agoI'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.
- SoftTalker 3y agoI'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 3y agoI'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 3y agoAlmost 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 3y ago[deleted]
- coder543 3y ago
- galacticaactual 3y agoStop. Releasing. Attack research. Without. Detection strategies.
- dralley 3y agoIt was reported to Intel a full year ago, apparently.
- foolswisdom 3y agoAnd yet they seem to still not have released the fix... Edit: they released the fix today, I was mislead by the current tense "is releasing" in the OP.
- thewataccount 3y agoThat 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 3y agoStop inserting random punctuation for emphasis! Periods go at the end of a full sentence.
- lokar 3y agoNot 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.
- theandrewbailey 3y agoThe detection strategy is: are you using the affected hardware?
- 3y ago
- deleted 3y ago[deleted]
- nwmcsween 3y agoHaven't RTFA but would zeroing registers fix this (-mzero-caller-saved-regs=used)?
- Findecanor 3y agoI 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.
- pornel 3y agoIn 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.
- deleted 3y ago[deleted]
- yakkityyak 3y agoNot again!
- baq 3y ago> [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 3y agoIt's not super revelatory given all the other Meltdown/Spectre bugs. I wouldn't read too much into it.
- nightpool 3y agoAMD 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 https://lock.cmpxchg8b.com/zenbleed.html, that might be what is being referenced here.
- deleted 3y ago[deleted]
- thewataccount 3y agoDoes 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?
- saagarjha 3y agoWorkloads that make heavy use of gather instructions. Typically scientific/HPC?
- mike_hearn 3y agoThe Intel paper link is dead, this seems to be the right one: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html?wapkw=gather%20data%20sampling 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).
- winternewt 3y agoThe 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-havoc-on-the-performance-of-some-Intel-CPUs-as-AMD-chips-come-out-largely-unscathed.607925.0.html https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
- mike_hearn 3y agoYes, 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.
- Negitivefrags 3y agoOnce 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.
- marssaxman 3y ago> For JavaScript it’s a bit harder. "We should probably just stop doing it" works for me.
- throwaway892238 3y agoAgreed. Browsers are now nothing but an application platform of APIs (https://developer.mozilla.org/en-US/docs/Web/API 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.
- sidewndr46 3y agoIf someone created a way for WASM to talk to an SDL equivalent, it'd probably end use of HTML & CSS
- yvdriess 3y agoAnd so closing the great circle of UI framework technologies.
- bruce343434 3y agoIs 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.
- matsemann 3y agoHere's a compilation: https://en.wikipedia.org/wiki/Transient_execution_CPU_vulnerability https://en.wikipedia.org/wiki/Transient_execution_CPU_vulner...
- deleted 3y ago[deleted]
- liamkearney 3y agoAs seen in the attack demo video the kernel advises of some. You can ‘cat /proc/cpuinfo’ and look for them there.
- throwaway892238 3y agoThis 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.
- aestetix 3y agoI just did a cursory readthrough. Am I correct to think this feels a bit like heartbleed, but for CPU registers rather than memory?
- GartzenDeHaes 3y agoHow could an attacker gain the level of knowledge necessary to accomplish this without compromising the target process?
- dwrodri 3y agoI'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 https://lock.cmpxchg8b.com/zenbleed.html
- GartzenDeHaes 3y agoHow 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.
- dwrodri 3y agoI'm gonna get put on a list for typing this out but I'll clarify: 1. Bad guy creates cloud account and spawns 10 of the cheapest VMs across different data centers, let's say this costs a total of, what... $50 a month? 2. Bad guy reads this paper, and makes a program that frequently samples SIMD registers. Contents get dumped to stdout and then streamed over an encrypted line to a RAID array hosted in $COUNTRY_WITHOUT_US_EXTRADITION. 3. Bad guy writes program to sift through data dumps on RAID array for passwords, encryption keys, etc. If you create a cloud instance right now that has an SSH login on port 22, you stream the SSH login logs and see a steady stream of attempted logins to your device. While the marginal cost of brute forcing SSH logins is free (no cloud VM needed) and my proposed scenario isn't, I think this is a very real scenario that needs monitoring.
- Veserv 3y agoI 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.
- adrian_b 3y agoIn the victim process, the following instructions leak information towards the attacker (because they share internal hidden buffers with the gather instructions executed by the attacker) (the following are quoted from the paper): • SIMD read. All SIMD operations that read wide data (128/256/512 bits) from memory are affected regardless of their function: e.g., vmov* only read, vpxor* read and compute the xor. These general-purpose instructions are used everywhere, e.g., compilers spread wide data reads to optimize memory access routines. • SIMD write. The only SIMD write operations that are affected are the compress ((v)(vp)compress*) instructions. • Cryptographic extensions. Cryptographic extensions, including AES-NI and SHA-NI (SHA1 and SHA256), when accepting a memory operand, are affected. Data leaks from these instructions expose plaintext data and the secret key, e.g., AES or HMAC-SHA. • Fast memory copy. Fast memory copies of various data types: byte, word, dword, qword using rep movs* instructions are affected. These are widely used to speed up common memory operations such as memcpy and memove. • Register context restore. Special instructions to more efficiently store/restore the register context (e.g., xsave/xrstor) are affected. GDS leaks the register context of both standard registers due to xsave/xrstor and wide registers due to fxsave/fxrstor. • Direct store The direct store is affected. Intel has recently added support for a direct store instruction that can copy a 64 bytes cache line from a source to a destination address.
- ndesaulniers 3y agoIntel Security Advisory: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/gather-data-sampling.html https://www.intel.com/content/www/us/en/developer/articles/t... Linux Kernel merge: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=64094e7e3118aff4b0be8ff713c242303e139834 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- ngneer 3y agoI 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.
- DarkNova6 3y agoHas there even be a documented practical attack in the wild?
- willy_k 3y agoDepends. This type of vulnerability is probably fairly valuable to state actors, for example.
- ngneer 3y agoAre state actors subject to different economics? Their budgets are finite, too. Why opt for a complex less reliable exploit if a simple more reliable one is available?
- EGreg 3y agoHow can the registers still hold this info when users switch? I would think that it is very transitory, and wiped by other stuff quickly
- CanaryLayout 3y agoThe OS job scheduler informs the CPU when it's ideal to swap jobs. But the OS is not doing the work of moving the register and stack pointers, the microcode is. These timing attacks take advantage of shared information in the cache (where it's likely the context of the thread you are not supposed to be able to read is). SMT (hyperthreading) introduces some ambiguity when the context change is going to happen, and it appears there's instructions that are callable where registers/mem can be read that were outside the calling context.
- ancris 3y agoAt this rate, with all these vulnerabilities and mitigations, we'll rollback CPU performance back at least 10 years.
- javajosh 3y agoYep it's almost like Moore's Law in reverse.
- IlliOnato 3y agoThe 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.
- Panzer04 3y agoGiven the classic stack overflow branch predictor question, you are underselling things quite a lot - a factor of 6 on those older processors in question, and who knows on modern processors. https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array https://stackoverflow.com/questions/11227809/why-is-processi...
- dzaima 3y agoI'd give at least a single order of magnitude for most code; maybe closer to two even.
- bob1029 3y agoIt seems to me like most don't have a fundamental gut feel for what speculative execution actually is and the implications of "not getting it". At some level we need to fight for performance. My operating systems are only getting slower and shittier. I cannot fathom my CPUs going backwards too. Security must take a back seat at some point. You can't put bubble wrap and warning labels over everything or it becomes useless. The most dangerous tools are typically the most effective. The CPUs are vulnerable because of the exact way in which they are being applied to a problem. Speculative execution is not inherently unsafe. Whatever future predicted memory prefetching shenanigans are going on in my CPU over here have absolutely ZERO impact on your CPU over there. Certainly someone could figure out a protocol/system/architecture that capitalizes on this notion that "2 different CPUs are indeed different CPUs". One can see how any perspective here still causes trouble for Amazon, Microsoft, et. al., but that was a business risk they signed up for the moment they intended to squeeze every last drop of subscriber revenue out of the hardware. Why should everyone else on earth have to suffer crappier performance by default because of the business/software practices of a select few?
- Dalewyn 3y agoAm 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.
- kzrdude 3y ago> Computing devices based on Intel Core processors from the 6th Skylake to (including) the 11th Tiger Lake generation are affected.
- bironran 3y agoWorth to note that GCP has this patched (https://cloud.google.com/support/bulletins#gcp-2023-024 https://cloud.google.com/support/bulletins#gcp-2023-024)
- palcu 3y agoMy 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.
- zgluck 3y agoCorresponding AWS notice: https://aws.amazon.com/security/security-bulletins/AWS-2023-007/ https://aws.amazon.com/security/security-bulletins/AWS-2023-... AWS customers’ data and instances are not affected by this issue, and no customer action is required. AWS has designed and implemented its infrastructure with protections against this class of issues. Amazon EC2 instances, including Lambda, Fargate, and other AWS-managed compute and container services protect customer data against GDS through microcode and software based mitigations.
- zerocrates 3y agoOnly 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.
- broodbucket 3y agoMicroarchitectural behaviour changes from generation to generation, and thus so do side effects. Fixing things by accident (and also introducing new problems by accident) are relatively frequent occurrences
- stevefan1999 3y agoFix one big bug, get two small bugs...
- locriacyber 3y agoWe should just call them "slimes".
- dncornholio 3y agoYes
- BeeOnRope 3y agoWhat 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?
- DropInIn 3y agoTinfoil 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 3y agoThis 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
- hinkley 3y agoOr 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.
- errantmind 3y agoThe 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 3y agoSimply removing the parameter didn't fix it? Or you just reinstalled grub to be sure it would work
- errantmind 3y agoThe 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.
- ftaghn 3y ago> Be warned, apparently Grub had some kind of problem back in August 2022 Are you referring to this? https://archlinux.org/news/grub-bootloader-upgrade-and-configuration-incompatibilities/ https://archlinux.org/news/grub-bootloader-upgrade-and-confi... This isn't the first time, and won't be the last time, something like that happens with grub, and it's entirely an issue with the user not doing what they should when they run archlinux or some other minimalist distribution that doesn't automate the process of updating grub. Grub uses a configuration file generator that reads from the human readable/editable /etc/default/grub and creates a /boot/grub/grub.cfg, and the result of that generator doesn't have a stable "interface". At any time, an update to grub might read grub.cfg incorrectly, if you do not generate it again. 99% of the linux distributions out there had no breakage with grub because they run the grub-mkconfig command every time grub is updated through grub-install. It is automated within the scripts included in the packaging of the distribution and the user will never see any of this in Debian, Ubuntu, Fedora etc. If a newer grub package comes out on those distro, the scripts will run both grub-install and grub-mkconfig. There will never be a mismatch between the grub binary versions and the config file state. Arch Linux users who knew how grub works also had no issue. If you update grub, you must regenerate the config file (it's a "if you update" because arch linux, by default, will NOT automatically update grub at all, updating the package is not the same as updating grub). If you edit the config file and regenerate it when you have a newer grub package installed, you must also update the grub binaries. So any time you do something with grub, you MUST run grub-install, then grub-mkconfig. Doing only one of the two is akin to doing a partial upgrade, which is a no-no. If, as I suspect, you're an arch user, I would recommend switching to systemd-boot, which doesn't even need a configuration file at all if you set up your system to follow its conventions and use unified kernel images. EFI binaries are automatically scanned and shown in the menu and it uses EFI variables to remember the few settings you can interactively edit, like the preferred kernel to boot. It's robust and only has what is needed in a small, KISS boot manager. It can't even be truly called a boot loader because that part is managed by efistub which is part of the unified kernel image. Very unlike grub, which has the whole kitchen sink, including its own implementation of a ton of filesystems..
- kzrdude 3y agoSee this LWN story: https://lwn.net/Articles/940783/ 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..
- kzrdude 3y agoMaybe that's not the default? Not entirely clear from the text.
- Bu9818 3y ago`[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12` I'm on haswell. Is there a list of what CPUs get updated microcode? Sad.
- starlevel003 3y agohaswell isn't vulnerable, it only affects skylake or later
- hansendc 3y agoThe AVX disable is only when you use "gather_data_sampling=force". The default is to leave AVX alone and proclaim the system to be vulnerable. From https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=553a5c03e90a https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... : > Specifying "gather_data_sampling=force" will use the microcode mitigation when > available or disable AVX on affected systems where the microcode hasn't been > updated to include the mitigation. Disclaimer: I work on Linux at Intel. I probably wrote or tweaked the documentation and changelogs that are confusing folks.
- kzrdude 3y agoGreat, thanks for the clarification
- lefuturiste 3y agoAs I see, there is no debian security release yet?
- kzrdude 3y agoThis from debian should indicate which version has the microcode update: 3.20230808.1 https://security-tracker.debian.org/tracker/CVE-2022-40982 https://security-tracker.debian.org/tracker/CVE-2022-40982
- Aaronmacaron 3y agoAre there any known attacks which exploited Spectre or Meltdown vulnerabilities? And is it likely that this vulnerability will be successfully used to perform attacks?
- xyst 3y agoSo it seems like speculative execution cannot be disabled. What’s the mitigation here? Nothing and wait for patch or significant redesign?
- snvzz 3y agoISA complexity breeds microarchitecture bugs. In the internet era, x86 is an anachronism. RISC is the way forward. RISC-V is inevitable.
- acdha 3y agoThis isn’t true - note how similar vulnerabilities have occurred on ARM, POWER, etc. – and even if you weren’t wrong, it would be off-topic for this thread since you’re not giving anyone useful information.
- snvzz 3y ago>This isn’t true - note how similar vulnerabilities have occurred on ARM, POWER, etc. I understand you're trying to argue against my main point, which is: >ISA complexity breeds microarchitecture bugs. And definitely stands. From there I have no idea how you derived that bugs are impossible under a simple ISA, which is implied in your statement. As an added note: ARM in particular isn't simple. It's simpler than x86, but that's a low bar to meet. >even if you weren’t wrong, it would be off-topic We will have to agree to disagree on this.
- CanaryLayout 3y agoOn a certain level this is like arguing that you will never see this problem in an Arduino. I mean, sure. On many levels and planes you are correct, but not where any of the intersections matter.
- snvzz 3y agoIf it's not clear enough, I am not talking whatever Arduino strawman you came up with. I am talking about RISC architectures such as RISC-V (which I mentioned by name), the sort that can scale all the way up to supercomputers and down to microcontrollers. There is no justification for putting up with x86's complexity. This complexity has negative consequences such as vastly increased likeliness of micro-architectural bugs. It is utter madness for many of its current popular uses, such as in servers handling personal data.
- tamimio 3y agoSo my CPU from 2015 (CPUID 306C3) - Is not affected - Doesn’t support Win11 And both are good to know.
- coding123 3y agoI guess 1995 is calling when computers were expensive.
- CanaryLayout 3y agoThe NES incorporated a chipset that buried an entire 6502 inside. You can get a Rockchip ARM chip for the price of a pizza that incorporates mixed cores on the die. Maybe the chipmakers don't NEED to solve every edge case until the end of time, but delegate side channel attack mitigations like this back to the chipgobblers (us). Hear me out: Instead of making SMT an all-or-nothing pre oposition, we have "lousy cores" where untrusted code goes and make the customer "prove" it should get elevation to the cores with SMT? I dont't want to clobber my chip that's running the mega-important payroll jobs where no one can load anything else on to the board under pain of death. However I would like to be forced into tagging what is safe to run SMT else I get stuck on the safer cores. I might be an intern who has no idea what any of this stuff means and goes to Google it, then learn what this attack vector truly is. Then makes a plan on how to defend against it. Am I crazy?
- dormento 3y agoI think its a market thing. You can have performance cores x efficiency cores. You do now want to be the one who proposes trusted cores x "lousy" (untrusted) cores. The benefits, however many, would be lost in the discourse of "promoting insecurity". Such is life.
- sholladay 3y agoIt feels like chipmakers never learned to "Make it work, make it right, make it fast", in that order. But then, hindsight is 20/20. How much slower would processors be if they got rid of all complex / risky optimizations? How much performance could we gain back with more expensive components, more integration (e.g. SoCs), and other approaches that are unlikely to lead to security problems?
- weebull 3y agoHow much slower? - we diable speculative execution, so every conditional branch goes for 1 cycle to the pipeline depth (5, 10, 20 cycles) to evaluate. Probably a 2x to 3x hit on performance. - we disable prefetching, so every cache miss now has the full memory latency delay to fill a cache line. 1.2 to 1.3x hit??? - We disable SIMD as per this issue. 4x-8x hit on those parts of the code that usebit. - If we need to go as far as disabling caching you can now only run instructions at the speed of main memory. 100x hit. CPUs would only be faster than their 1970s ancestors because the clock speed was now 5GHz and not 1 MGHz.
- brundolf 3y agoSpeculative execution seems like a never-ending rabbit hole of vulnerabilities. Though I feel like most of them end up being in Intel chips for some reason
- isoprophlex 3y agoI guess Moore's law isn't exactly dead, but it doesn't seem to be alive either... Moore's law is undead?
- entriesfull 3y agoSo this is literally the same thing as AMD's Zenbleed vulnerability? Ridiculous how these companies make so much money and are completely incompetent at handling security. Theoretically, this can be mitigated permanently by disabling hyper-threading?
- wqqwdfsaadd 3y ago[dead]
- SomeoneFromCA 3y agoSimilar to Zenbleed judging by description.