“The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum”- Everything shared is based on personal memories – Events unfold in parallel and the experiences and perspectives highly depend on the moment (bias, past experience/knowledge, priorities and emotional situation) of the observer – I always did my best to be sure that those around/close to me are heard too – I will always be more forgiven to those below than to those above me- None of this is intended as personal attacks, therefore I omitted names and only talk about positions/titles when the relative power (and how it was used) of the decision maker is relevant I use tons of generalizations knowing very well generalizations are risky and unfair to many – In order to be fast, I hope one alert about it could cover all cases during the talk (yes, I am aware that is not how communication works)- During the talk, I praise companies, researchers and technologies because I believe in them, not because of any personal benefit- Started with CPU bugs by accident, while researching SMM (2007) – so 15+ years – Worked for Intel, AWS, Google doing CPU/Platform Security (11+ years)Tons of horror stories, lots of learnings and lots of great people (my opinions are forged from those experiences and interactions) Jan 2019: https://www.wired.com/story/intel-meltdown-spectre-storm/CVE-2023-1998, CVE-2023-00045, CVE-2020-12965, CVE-2020-0543, CVE-2019-0185, CVE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2019-0151, CVE-2019-0152, CVE-2019-0117, CVE-2019-0184, CVE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2019-0151, CVE-2019-0152, CVE-2019-0117, CVE-2019-0184, CVE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresStill, I’m a failure! And this talk is (mostly) about that failure (so hopefully you don’t have to fail asE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2019-0151, CVE-2019-0152, CVE-2019-0117, CVE-2019-0184, CVE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2019-0151, CVE-2019-0152, CVE-2019-0117, CVE-2019-0184, CVE-2019-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featureshow bad it is, and how simple things really are (demystifying the myth of this been super hard thus why the problems persist)9-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel features9-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresI want more researchers to understand that they can (and are) changing things (even though individuals in certain companies might dismiss their9-0155, CVE-2019-14590, CVE-2019-14591, CVE-2019-11089, CVE-2019-11113, CVE-2018-3693, CVE-2018-12126, CVE-2018-12130, CVE-2018-12127, CVE-2019-11091, CVE-2019-0115, CVE-2018-12209, CVE-2018-12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel features● I believe it’s a rule rather than an exception that the potential for vulnerabilities (and therefore, exploits) is already present at the design stage, and as so, can be anticipated at that stageacross systems and therefore can be abstracted/generalized ○ That essentially mean that the root cause is not in the specific details, but12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel features○ What we don’t know, but should know ○ What we are not able to do, but should be able to ○ What is the taxonomy of past security issues?across systems and therefore can be abstracted/generalized ○ That essentially mean that the root cause is not in the specific details, but12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresacross systems and therefore can be abstracted/generalized ○ That essentially mean that the root cause is not in the specific details, but12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresacross systems and therefore can be abstracted/generalized ○ That essentially mean that the root cause is not in the specific details, but12210, CVE-2018-12211, CVE-2018-12212, CVE-2018-12213, CVE-2018-12214, CVE-2018-12215, CVE-2018-12216, CVE-2018-12217, CVE-2018-3626, CVE-2018-5736, CVE-2019-0162, CVE-2018-3615, CVE-2018-3620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresFollowed by an Intel SPE talk at Oregon State University. The myth of the ‘cache-line boundary side-channel’ is a Software Problem is bornI raise the alert that more exploit-dev researchers will look at it. I propose to initiate an effort to look for side channels. By march management said ‘Yes’, but the decision gets reverted back because the security ‘Fellow’ said there was no ROI620, CVE-2018-3646, CVE-2018-3665, CVE-2018-3639, CVE-2018-3640, CVE-2017-5753, CVE-2017-5754, CVE-2017-5715 20+ patents (covering CFI, side-channels, encrypted memory, etc) that impacted in major Intel featuresDue to a PoC error, Anders did not find the issue. But had the right insight. Inspired others to look at itI get the report in the same day. After reproducing and understanding (couple of days), I’ve raised the flag that this was a ‘New Class of Issues’First Linux Kernel Patches (Kaiser) are upstreamed Somehow Linus Torvalds is not vocal (at all) about them. Patches start getting accepted, so folks that saw Ander’s work get suspicious that there is something – Others find the issues and reportNew Intel organization formed (6 VPs, no employees – the generals-only army), CEO says HW fixes underway (untrue, complicates matters). Class action lawsuits (many, but a major one in US and another one in Israel). Academics jump on itThanks to Truc Nguyen for convincing me to join Intel Thanks to Burzin Daruwala, Dhinesh Manoharan and David Daughty (now at AWS) for listening to me and making real changes! (that really kept me around) Thanks to Gabriel Barbosa (now at AWS) for the amazing guidance when I joined and outstanding brainstormings and fun interactions over the many years we work together Thanks to Matt King (now at Nvidia) for the ‘Core Dump’ Thanks to Yuriy Bulygin (now at Eclypsium) for the amazing guidance when I joined Thanks to Shay Gueron (now at AWS) for replying to my email stating that I was bored and would leave – Shay gave me an interesting challenge to work on (Memory Encryption Attacks)! And for the overall guidance and support over the years – that is real mentorship!Thanks to Truc Nguyen for convincing me to join Intel Thanks to Burzin Daruwala, Dhinesh Manoharan and David Daughty (now at AWS) for listening to me and making real changes! (that really kept me around) Thanks to Gabriel Barbosa (now at AWS) for the amazing guidance when I joined and outstanding brainstormings and fun interactions over the many years we work together Thanks to Matt King (now at Nvidia) for the ‘Core Dump’ Thanks to Yuriy Bulygin (now at Eclypsium) for the amazing guidance when I joined Thanks to Shay Gueron (now at AWS) for replying to my email stating that I was bored and would leave – Shay gave me an interesting challenge to work on (Memory Encryption Attacks)! And for the overall guidance and support over the years – that is real mentorship!(that really kept me around) Thanks to Gabriel Barbosa (now at AWS) for the amazing guidance when I joined and outstanding brainstormings and fun interactions over the many years we work together Thanks to Matt King (now at Nvidia) for the ‘Core Dump’ Thanks to Yuriy Bulygin (now at Eclypsium) for the amazing guidance when I joined Thanks to Shay Gueron (now at AWS) for replying to my email stating that I was bored and would leave – Shay gave me an interesting challenge to work on (Memory Encryption Attacks)! And for the overall guidance and support over the years – that is real mentorship!(that really kept me around) Thanks to Gabriel Barbosa (now at AWS) for the amazing guidance when I joined and outstanding brainstormings and fun interactions over the many years we work together Thanks to Matt King (now at Nvidia) for the ‘Core Dump’ Thanks to Yuriy Bulygin (now at Eclypsium) for the amazing guidance when I joined Thanks to Shay Gueron (now at AWS) for replying to my email stating that I was bored and would leave – Shay gave me an interesting challenge to work on (Memory Encryption Attacks)! And for the overall guidance and support over the years – that is real mentorship!(that really kept me around) Thanks to Gabriel Barbosa (now at AWS) for the amazing guidance when I joined and outstanding brainstormings and fun interactions over the many years we work together Thanks to Matt King (now at Nvidia) for the ‘Core Dump’ Thanks to Yuriy Bulygin (now at Eclypsium) for the amazing guidance when I joined Thanks to Shay Gueron (now at AWS) for replying to my email stating that I was bored and would leave – Shay gave me an interesting challenge to work on (Memory Encryption Attacks)! And for the overall guidance and support over the years – that is real mentorship!indeed were disclosed) It is been a few years and still some were not fixed, some were silently fixed, some were found later by others or re-reported by Intel somehow. E.g.,: CVE-2020-12965, intel-sa-00706um) for the amazing guidance when I joined Thanks to Shay Gueron (now at AWS) for replying to my email stating that I was bored and would leave – Shay gave me an interesting challenge to work on (Memory Encryption Attacks)! And for the overall guidance and support over the years – that is real mentorship!reports or from the pressure from Intel), but clearly with someone aligned with Intel (as in: AMD literally consults with Intel for responses and admits – to some gang members at least – that they have no team working on those issues) Immediately the collaboration with AMD became problematic (I was in a cloud provider by then)ones) In the past, when AMD had too many issues in a given area, as a customer we would talk to them and really help their team better cover the topic (e.g.: I had a session with their graphics drivers team to help them improve coverage to stop having bugs reported by Cisco Talos)- They proxy responses, literally making collaboration a one way street (there are many public examples and literally everyone complaining that they send all info but receive nothing back) Instead of fostering (and truly leveraging) collaboration, they created the ‘Gang of’ (initially Gang of 4, later Gang of 10, now Gang of 20+): representatives from major companies and projects that receive private informationThis became a career benefit, and literally a ‘Gang’ The original idea made sense: to be sure the impact of certain issues are understood industry-wide – Remember Intel’s deposition on Congress due to reporting issues to a OEM in China but not to US CERT?So many examples of failures to look at, from the inconsistencies in their advisories (like even how things are root-caused or how impact/severity isinitially Gang of 4, later Gang of 10, now Gang of 20+): representatives from major companies and projects that receive private informationThis became a career benefit, and literally a ‘Gang’ The original idea made sense: to be sure the impact of certain issues are understood industry-wide – Remember Intel’s deposition on Congress due to reporting issues to a OEM in China but not to US CERT?● Collision by different researchers (paper) ● (CVE-2019-11157 / INTEL-SA-00289) ● Intel notified somewhere in June 2019, issue published on December 2019○ Commit: a7e1f67ed29f (Jun/2020) – “x86/msr: Filter MSR writes” ○ By end of Jan/2021, another fix (“As msr register can be written by X86_IOC_WRMSR_REGSadvisory does not specifically list anything hypervisor related, just SGX (as is the case of the papers) ○ But Intel did investigate further (I was there) ○ SMM/Hypervisor obviously affected● CVE-2022-24436 (Intel), CVE-2022-23823 (AMD) (again, inconsistency) ● INTEL-SA-00698 – No mention about hypervisors ● I’ve contacted Intel PSIRT to let them know that their advisory shouldexplicitly mention the hypervisor case and that many likely would not notice the problem (I did it before the issue became public). ○ ○To exemplify the matter, I pointed out that the feature was accessible to guests running on Xen Their response came from their PSIRT VP, but not to me, instead, an escalation to the VP of another group in the company and was along the lines of this:(AMD) (again, inconsistency) ● INTEL-SA-00698 – No mention about hypervisors ● I’ve contacted Intel PSIRT to let them know that their advisory shouldexplicitly mention the hypervisor case and that many likely would not notice the problem (I did it before the issue became public). ○ ○To exemplify the matter, I pointed out that the feature was accessible to guests running on Xen Their response came from their PSIRT VP, but not to me, instead, an escalation to the VP of another group in the company and was along the lines of this:Interesting research done by José Luiz Negreira Castro de Oliveira (the research *was* complicated) Jose reported it to Intel (another funny PSIRT f***-up that I will share later), but the work caught my attention (when it was published, I wasn’t at Intel anymore)wants to control the branch prediction entries in order to redirect the victim to cause a leak Therefore, the flow for the attack requires attacker and then victim scheduled (as close as possible to increase reliability) IBPB did not consider the actual ‘entries’ to be secret (even though it does erase the entries)before a trusted one, they might have a situation in which they are still vulnerable I was very surprised that Intel researchers completely missed thatIn talking with Jose, it seemed that the main limitation was the actual targets. In brainstorming how to increase the applicability of the attack, we agreed that rets could also be used (and are more prominent than other indirect branches) – so we testedwants to control the branch prediction entries in order to redirect the victim to cause a leak Therefore, the flow for the attack requires attacker and then victim scheduled (as close as possible to increase reliability) IBPB did not consider the actual ‘entries’ to be secret (even though it does erase the entries)before a trusted one, they might have a situation in which they are still vulnerable I was very surprised that Intel researchers completely missed thatre, the flow for the attack requires attacker and then victim scheduled (as close as possible to increase reliability) IBPB did not consider the actual ‘entries’ to be secret (even though it does erase the entries)before a trusted one, they might have a situation in which they are still vulnerable I was very surprised that Intel researchers completely missed that- When we reported top of the stack (Jul 07 – 2022), we had a sentence in the paper: “in case- Got a response a week later saying there was nothing new there (but asking to keep secret for 90 days).- After the 90 days, we published the write-up and got a request from AMD to delete the sentence (the only difference is we specifically said ‘on some AMD microarchitectures’)- When we reported top of the stack (Jul 07 – 2022), we had a sentence in the paper: “in case- Got a response a week later saying there was nothing new there (but asking to keep secret for 90 days).- After the 90 days, we published the write-up and got a request from AMD to delete the sentence (the only difference is we specifically said ‘on some AMD microarchitectures’)- The signals got root-caused to be really deep paths inside the kernel (Linux) – mostly related to interrupt handling (and the ‘Fellow’ randomly decided without any actual data, analysis or even having worked on developing PoCs/exploits in their life that was uncommon)that ALL affected systems that had to do the RSB filling would need to have BIOS updates – making retpoline way less attractive/realistic) – we were told that Google and Cloud Providers controlled their own BIOS, so it was not relevantanalysis of Variant 2) that on some uarches, the rets were going to BTB if the RSB was empty (so ucode patches needed too)(that was not released yet, but upcoming) – notice that we had already flagged that CET ‘endbranch’ should serialize (terminate) speculationThey forgot to stuff the RSB for their SMI handlers They forgot to apply the ucode patch on broadwell systems (therefore, they were also vulnerable to ret->BTB) They forgot that the RSB Filling code on the kernel was interruptible and therefore, RSB refilling had to happen in every interrupt handler return (is that fixed in mainstream yet?) They forgot that they supported nested guests… (that got a patch sent mainstream without credits, of course)Side-channels are irrelevant, Intel/AMD are good at everything else (security-wise I mean, forget delays, quality)… – Wasn’t it AMD SEV that had basic encryption problems? (not even considering the fact that registers were not encrypted and their whitepaper claimed that any memory write would lead to a crash only?)- What about AMD’s fTPM? – What about all the UEFI flaws? Malicious actors are noticing more and moreBinarly finally gave an industry-wide view/ability for issues (300+ found in one year) IOActive and NCC Group researcher have been constantly finding things- What about transparency? (ucode updates without any specific info on what they fix) – What about Taviso’s recent work (reproducing an AMD errata and demonstrating that AMD forgot toecurity-wise I mean, forget delays, quality)… – Wasn’t it AMD SEV that had basic encryption problems? (not even considering the fact that registers were not encrypted and their whitepaper claimed that any memory write would lead to a crash only?)- What about AMD’s fTPM? – What about all the UEFI flaws? Malicious actors are noticing more and moreBinarly finally gave an industry-wide view/ability for issues (300+ found in one year) IOActive and NCC Group researcher have been constantly finding things- What about transparency? (ucode updates without any specific info on what they fix) – What about Taviso’s recent work (reproducing an AMD errata and demonstrating that AMD forgot toSMM/TXT) – even got a pwnied awards somehow Issue found by Gabriel Barbosa and myself on how ucode cache works… given it does not keep mode information (instructions with different semantics between user-mode and kernel-mode end-up can’t be differentiated) – MPX was the only case found, very irrelevant but super interesting, became an errata (details here) – Open Source Security Inc. (grsecurity folks) also disclosed a nice errata that theyupdates without any specific info on what they fix) – What about Taviso’s recent work (reproducing an AMD errata and demonstrating that AMD forgot toSMM/TXT) – even got a pwnied awards somehow Issue found by Gabriel Barbosa and myself on how ucode cache works… given it does not keep mode information (instructions with different semantics between user-mode and kernel-mode end-up can’t be differentiated) – MPX was the only case found, very irrelevant but super interesting, became an errata (details here) – Open Source Security Inc. (grsecurity folks) also disclosed a nice errata that theyupdates without any specific info on what they fix) – What about Taviso’s recent work (reproducing an AMD errata and demonstrating that AMD forgot toSGX is implement in client, not servers (so the MPH is different) SGX uses MEE as the encryption mechanism, that has integrity and replay protection (backed by an internal SRAM). TDX does not even have integrity/replay protectionsupported on one or another (like FuSA requirements for Client SoCs and RAS features for Servers) XuCode logic is different, given that:SGX is implement in client, not servers (so the MPH is different) SGX uses MEE as the encryption mechanism, that has integrity and replay protection (backed by an internal SRAM). TDX does not even have integrity/replay protectionsupported on one or another (like FuSA requirements for Client SoCs and RAS features for Servers) XuCode logic is different, given that:SGX is implement in client, not servers (so the MPH is different) SGX uses MEE as the encryption mechanism, that has integrity and replay protection (backed by an internal SRAM). TDX does not even have integrity/replay protectionsupported on one or another (like FuSA requirements for Client SoCs and RAS features for Servers) XuCode logic is different, given that:that in the past folks used complexity as an excuse to not improve things) – I honestly believe it is way simpler than modern exploitation on major OSes/software(part of key companies) and, because their unawareness of security (they are from marketing or developers), they are making the same mistakes that we’ve seeing in the 90s (like attacking researchers instead of trying to collaborate, assuming that collaboration = submission/acceptance) I didn’t even discuss supply chain considerations for HW security (and how more and more things like secureboot on different devices will matter) – go look at storage controllers, switches, etc (if Intel/AMD still make trivial mistakes…)hide even further compromises) – a lot of technology has yet to be developed – anyone jumping into using it should not lie to themselves they are doing it for security reasons :)- Too many secrets concentrated in one technology set – Research on attacks leveraging multi-tech capabilities are still non-existent – They can do way more than standalone companies, but savings at scale, problems inceptance) I didn’t even discuss supply chain considerations for HW security (and how more and more things like secureboot on different devices will matter) – go look at storage controllers, switches, etc (if Intel/AMD still make trivial mistakes…)ceptance) I didn’t even discuss supply chain considerations for HW security (and how more and more things like secureboot on different devices will matter) – go look at storage controllers, switches, etc (if Intel/AMD still make trivial mistakes…)Flushes (of secrets, of untrusted control entries) Serialization/Stopping speculation (at key points, at certain flows, to stop speculation) – it can be a serializing instruction (like lfence), disabling it entirely (like IBRS) or marking things as non-cacheable at all Partitioning (as a way to make the other two performant – like AWS using ASI-like in their hypervisor and not been affected by most of the side-channels that came after Variants 1-3)Flushes (of secrets, of untrusted control entries) Serialization/Stopping speculation (at key points, at certain flows, to stop speculation) – it can be a serializing instruction (like lfence), disabling it entirely (like IBRS) or marking things as non-cacheable at all Partitioning (as a way to make the other two performant – like AWS using ASI-like in their hypervisor and not been affected by most of the side-channels that came after Variants 1-3) [summary]
Source link