<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: &#8216;Kernel memory leaking&#8217; Intel processor design flaw</title>
	<atom:link href="http://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/</link>
	<description>All about electronics and circuit design</description>
	<lastBuildDate>Fri, 10 Apr 2026 21:14:09 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.9.14</generator>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1820766</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Fri, 12 Jan 2024 19:25:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1820766</guid>
		<description><![CDATA[https://testbit.eu/2023/cgroup-cpuset]]></description>
		<content:encoded><![CDATA[<p><a href="https://testbit.eu/2023/cgroup-cpuset" rel="nofollow">https://testbit.eu/2023/cgroup-cpuset</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1811597</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Wed, 23 Aug 2023 14:41:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1811597</guid>
		<description><![CDATA[By Sayan Sen - Microsoft and Intel have cautioned about a recent security vulnerability affecting 7th Gen, 8th Gen, 9th Gen, 10th Gen, and 11th Gen chips. This security vulnerability is called Downfall or GDS. #Intel #Microsoft #Downfall

https://www.neowin.net/news/gds-microsoft-intel-confirm-downfall-of-7th-8th-9th-10th-11th-gen-cpus-firmware-out/?fbclid=IwAR1pwmpyZ_-qtIDc7Z-aTa_wYtQhrk5-w92ITL3xpk2V9ia2jD5H7ZuryLQ]]></description>
		<content:encoded><![CDATA[<p>By Sayan Sen &#8211; Microsoft and Intel have cautioned about a recent security vulnerability affecting 7th Gen, 8th Gen, 9th Gen, 10th Gen, and 11th Gen chips. This security vulnerability is called Downfall or GDS. #Intel #Microsoft #Downfall</p>
<p><a href="https://www.neowin.net/news/gds-microsoft-intel-confirm-downfall-of-7th-8th-9th-10th-11th-gen-cpus-firmware-out/?fbclid=IwAR1pwmpyZ_-qtIDc7Z-aTa_wYtQhrk5-w92ITL3xpk2V9ia2jD5H7ZuryLQ" rel="nofollow">https://www.neowin.net/news/gds-microsoft-intel-confirm-downfall-of-7th-8th-9th-10th-11th-gen-cpus-firmware-out/?fbclid=IwAR1pwmpyZ_-qtIDc7Z-aTa_wYtQhrk5-w92ITL3xpk2V9ia2jD5H7ZuryLQ</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1811303</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Mon, 21 Aug 2023 08:41:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1811303</guid>
		<description><![CDATA[Zenbleed: new hardware vulnerability in AMD CPUs
Explaining an issue in popular PC and server CPUs in simple terms.
https://www.kaspersky.com/blog/zenbleed-vulnerability/48836/
Zenbleed exists thanks to the speculative execution system. The vulnerability is not easy to explain. In his blogpost, Tavis Ormandy presents cold facts that only an experienced low-level coding pro can get to the bottom of. In a nutshell, here is one of the instruction sets for Zenbleed exploitation:
A GitHub description by the Google Information Security team sheds some light on the nature of the problem. For the past 15 years, Intel and AMD CPUs have been using the instruction extension set AVX. Among other things, these instructions support 128- and 256-bit vector registers. To put it really simple, CPU registers are used for temporary storage of data when executing instructions. In some cases, being able to store sufficiently large amounts of data in vector registers allows to considerably improve performance. The 128 bit (XMM) and 256 bit (YMM) registers are commonly used for the most routine operations, such as related to read/write from/to RAM.
Concurrent use of 128 and 256 bit registers brings another set of problems. If used simultaneously within the same task, XMM registers are automatically converted into YMM registers. This is where the zeroing of the upper “half” of the YMM register is routinely performed. The special instruction for that is vzeroupper. All registers are stored in the so-called register file and are used in turns by different programs run on the computer.
https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed]]></description>
		<content:encoded><![CDATA[<p>Zenbleed: new hardware vulnerability in AMD CPUs<br />
Explaining an issue in popular PC and server CPUs in simple terms.<br />
<a href="https://www.kaspersky.com/blog/zenbleed-vulnerability/48836/" rel="nofollow">https://www.kaspersky.com/blog/zenbleed-vulnerability/48836/</a><br />
Zenbleed exists thanks to the speculative execution system. The vulnerability is not easy to explain. In his blogpost, Tavis Ormandy presents cold facts that only an experienced low-level coding pro can get to the bottom of. In a nutshell, here is one of the instruction sets for Zenbleed exploitation:<br />
A GitHub description by the Google Information Security team sheds some light on the nature of the problem. For the past 15 years, Intel and AMD CPUs have been using the instruction extension set AVX. Among other things, these instructions support 128- and 256-bit vector registers. To put it really simple, CPU registers are used for temporary storage of data when executing instructions. In some cases, being able to store sufficiently large amounts of data in vector registers allows to considerably improve performance. The 128 bit (XMM) and 256 bit (YMM) registers are commonly used for the most routine operations, such as related to read/write from/to RAM.<br />
Concurrent use of 128 and 256 bit registers brings another set of problems. If used simultaneously within the same task, XMM registers are automatically converted into YMM registers. This is where the zeroing of the upper “half” of the YMM register is routinely performed. The special instruction for that is vzeroupper. All registers are stored in the so-called register file and are used in turns by different programs run on the computer.<br />
<a href="https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed" rel="nofollow">https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1811302</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Mon, 21 Aug 2023 08:39:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1811302</guid>
		<description><![CDATA[https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/
AWS, Microsoft Azure, Google Cloud 
AWS said its customers’ data and cloud instances are not affected by Downfall and no action is required. The cloud giant did note that it has “designed and implemented its infrastructure with protections against this class of issues”. 
Microsoft said it rolled out updates to its Azure infrastructure to patch the vulnerability. In most cases — except customers that have opted out of automatic updates — users do not need to take any action.  
Google Cloud also said no customer action is required. The company has applied available patches on its server fleet. However, some products require additional updates from its partners or vendors. 
Dell 
Dell has released BIOS patches for Alienware, ChengMing, G series, Precision, Inspiron, Latitude, OptiPlex, Vostro, and XPS computers. 
HP 
HP has started releasing SoftPaqs that address Downfall for its business and consumer PCs, workstations, and retail PoS systems.  
VMware 
VMware informed customers that hypervisors may be affected by CVE-2022-40982 if they are using an impacted Intel CPU, but hypervisor patches are not needed to address the vulnerability. Instead, impacted customers need to obtain firmware updates from their hardware vendors. 
Linux distributions 
Several Linux distributions have released advisories, patches and mitigations for systems using Intel processors. The list includes SUSE, CloudLinux, RedHat, Ubuntu and Debian.]]></description>
		<content:encoded><![CDATA[<p><a href="https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/" rel="nofollow">https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/</a><br />
AWS, Microsoft Azure, Google Cloud<br />
AWS said its customers’ data and cloud instances are not affected by Downfall and no action is required. The cloud giant did note that it has “designed and implemented its infrastructure with protections against this class of issues”.<br />
Microsoft said it rolled out updates to its Azure infrastructure to patch the vulnerability. In most cases — except customers that have opted out of automatic updates — users do not need to take any action.<br />
Google Cloud also said no customer action is required. The company has applied available patches on its server fleet. However, some products require additional updates from its partners or vendors.<br />
Dell<br />
Dell has released BIOS patches for Alienware, ChengMing, G series, Precision, Inspiron, Latitude, OptiPlex, Vostro, and XPS computers.<br />
HP<br />
HP has started releasing SoftPaqs that address Downfall for its business and consumer PCs, workstations, and retail PoS systems.<br />
VMware<br />
VMware informed customers that hypervisors may be affected by CVE-2022-40982 if they are using an impacted Intel CPU, but hypervisor patches are not needed to address the vulnerability. Instead, impacted customers need to obtain firmware updates from their hardware vendors.<br />
Linux distributions<br />
Several Linux distributions have released advisories, patches and mitigations for systems using Intel processors. The list includes SUSE, CloudLinux, RedHat, Ubuntu and Debian.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1811301</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Mon, 21 Aug 2023 08:38:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1811301</guid>
		<description><![CDATA[https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/
The OpenSSL Project published a blog post this week pointing out that while the Downfall attack has been demonstrated against OpenSSL, it’s “highly general microarchitectural side-channel attack which can compromise the security of essentially any software”.
“Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high,” the OpenSSL Project explained.  
OpenSSL Statement on the Recent Intel/AMD Downfall/Inception Vulnerabilities
https://www.openssl.org/blog/blog/2023/08/15/downfall/
What this attack enables
If an attacker can obtain local (but unprivileged) execution on a machine with an affected CPU, and they are able to schedule that process on the same physical core as another process, and they are able to execute AVX instructions, you should assume they are able to obtain read access to any information stored within that process’s memory.
It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.
The requirement for executing on the same physical core as a victim process can be met either by OS context switching or via hyperthreading.
Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high.
However, this does not mean that other information stored in a process is not vulnerable to compromise and we would recommend that users assume that all information stored in a vulnerable process is accessible to an attacker. While there are potentially limitations to the exploitation techniques published, the qualifiers to any such limitations are sufficiently complex to be unable to make assurances in any particular area.
Recommended mitigation
The following mitigations are available:
•	Intel have released microcode updates for affected CPUs and the best course of action to mitigate these vulnerabilities is to deploy these microcode updates as soon as possible.
•	In the absence of the ability to deploy these microcode updates, an alternative mitigation is to disable the ability to use AVX instructions in any untrusted process. This will generally require an OS update; for example, a mitigation patch is now available for the Linux kernel which allows this to be configured. Disabling AVX may break applications which have been designed or compiled under the assumption that AVX is available.
It should be emphasised that a victim process does not need to execute AVX instructions to be affected. Exploitation can only be mitigated by preventing an attacker process from executing AVX instructions.
The immediate indicated mitigation action is to install the microcode updates providing mitigation for this vulnerability provided by Intel, or system firmware updates incorporating those microcode updates provided by your system vendor. Further information on how to deploy these microcode updates is available below.
The disabling of AVX should be seen as a fallback mitigation where it is not feasible to deploy these microcode or system firmware updates.
The following are not effective mitigations:
•	A victim process cannot render itself immune to exploitation by refraining from use of AVX instructions, or all SIMD instructions. While the Downfall vulnerability targets code which makes use of 128-bit or wider data accesses, this includes the standard x86 XSAVE instruction which OS kernels use to save and restore process context. Therefore, even if an application recompiled itself to avoid any use of any SIMD instruction whatsoever, the contents of its registers would be exposed to an attacker whenever a context switch occurs.
It may be possible to provide mitigation by scheduling untrusted processes on separate physical cores to trusted processes, however we would not recommend trying to adopt this as a mitigation strategy, as it requires users to accurately classify trusted and untrusted processes, and to correctly configure process scheduling affinity. 
https://kernel.org/doc/html/next/admin-guide/hw-vuln/gather_data_sampling.html]]></description>
		<content:encoded><![CDATA[<p><a href="https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/" rel="nofollow">https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/</a><br />
The OpenSSL Project published a blog post this week pointing out that while the Downfall attack has been demonstrated against OpenSSL, it’s “highly general microarchitectural side-channel attack which can compromise the security of essentially any software”.<br />
“Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high,” the OpenSSL Project explained.<br />
OpenSSL Statement on the Recent Intel/AMD Downfall/Inception Vulnerabilities<br />
<a href="https://www.openssl.org/blog/blog/2023/08/15/downfall/" rel="nofollow">https://www.openssl.org/blog/blog/2023/08/15/downfall/</a><br />
What this attack enables<br />
If an attacker can obtain local (but unprivileged) execution on a machine with an affected CPU, and they are able to schedule that process on the same physical core as another process, and they are able to execute AVX instructions, you should assume they are able to obtain read access to any information stored within that process’s memory.<br />
It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.<br />
The requirement for executing on the same physical core as a victim process can be met either by OS context switching or via hyperthreading.<br />
Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high.<br />
However, this does not mean that other information stored in a process is not vulnerable to compromise and we would recommend that users assume that all information stored in a vulnerable process is accessible to an attacker. While there are potentially limitations to the exploitation techniques published, the qualifiers to any such limitations are sufficiently complex to be unable to make assurances in any particular area.<br />
Recommended mitigation<br />
The following mitigations are available:<br />
•	Intel have released microcode updates for affected CPUs and the best course of action to mitigate these vulnerabilities is to deploy these microcode updates as soon as possible.<br />
•	In the absence of the ability to deploy these microcode updates, an alternative mitigation is to disable the ability to use AVX instructions in any untrusted process. This will generally require an OS update; for example, a mitigation patch is now available for the Linux kernel which allows this to be configured. Disabling AVX may break applications which have been designed or compiled under the assumption that AVX is available.<br />
It should be emphasised that a victim process does not need to execute AVX instructions to be affected. Exploitation can only be mitigated by preventing an attacker process from executing AVX instructions.<br />
The immediate indicated mitigation action is to install the microcode updates providing mitigation for this vulnerability provided by Intel, or system firmware updates incorporating those microcode updates provided by your system vendor. Further information on how to deploy these microcode updates is available below.<br />
The disabling of AVX should be seen as a fallback mitigation where it is not feasible to deploy these microcode or system firmware updates.<br />
The following are not effective mitigations:<br />
•	A victim process cannot render itself immune to exploitation by refraining from use of AVX instructions, or all SIMD instructions. While the Downfall vulnerability targets code which makes use of 128-bit or wider data accesses, this includes the standard x86 XSAVE instruction which OS kernels use to save and restore process context. Therefore, even if an application recompiled itself to avoid any use of any SIMD instruction whatsoever, the contents of its registers would be exposed to an attacker whenever a context switch occurs.<br />
It may be possible to provide mitigation by scheduling untrusted processes on separate physical cores to trusted processes, however we would not recommend trying to adopt this as a mitigation strategy, as it requires users to accurately classify trusted and untrusted processes, and to correctly configure process scheduling affinity.<br />
<a href="https://kernel.org/doc/html/next/admin-guide/hw-vuln/gather_data_sampling.html" rel="nofollow">https://kernel.org/doc/html/next/admin-guide/hw-vuln/gather_data_sampling.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1811274</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Mon, 21 Aug 2023 07:28:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1811274</guid>
		<description><![CDATA[Companies Respond to ‘Downfall’ Intel CPU Vulnerability https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/

Several major companies have published advisories in response to the Downfall vulnerability affecting Intel CPUs.

Related for AMD: *Zenbleed: new hardware vulnerability in AMD CPUs* https://www.kaspersky.com/blog/zenbleed-vulnerability/48836/]]></description>
		<content:encoded><![CDATA[<p>Companies Respond to ‘Downfall’ Intel CPU Vulnerability <a href="https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/" rel="nofollow">https://www.securityweek.com/companies-respond-to-downfall-intel-cpu-vulnerability/</a></p>
<p>Several major companies have published advisories in response to the Downfall vulnerability affecting Intel CPUs.</p>
<p>Related for AMD: *Zenbleed: new hardware vulnerability in AMD CPUs* <a href="https://www.kaspersky.com/blog/zenbleed-vulnerability/48836/" rel="nofollow">https://www.kaspersky.com/blog/zenbleed-vulnerability/48836/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1810550</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Mon, 14 Aug 2023 09:50:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1810550</guid>
		<description><![CDATA[Gather Data Sampling / CVE-2022-40982 / INTEL-SA-00828
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/gather-data-sampling.html
Key Takeaways
•	Intel is providing a microcode update to mitigate GDS. No software changes are required to enable the mitigation. 
•	Users should carefully consider the threat model applicable to their systems when deciding whether and where to mitigate GDS.
•	Intel is not aware of any instance of any of this vulnerability being exploited outside a controlled lab environment. 
•	Operating system vendors (OSVs) provide options to opt out of the GDS mitigation. 

Gather Data Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processors. In some situations when a gather instruction performs certain loads from memory, it may be possible for a malicious attacker to use this type of instruction to infer stale data from previously used vector registers. Similar to data sampling transient execution attacks like Microarchitectural Data Sampling (MDS), GDS may allow a malicious actor who can locally execute code on a system to infer the values of secret data which is otherwise protected by architectural mechanisms. GDS differs from the MDS vulnerabilities in both the method of exposure (which is limited to the set of gather instructions), and in the data exposed (stale vector register data only). Neither MDS nor GDS, by themselves, provide malicious actors the ability to choose which data is inferred using these methods.
GDS is assigned CVE-2022-40982 CVSS Base Score 6.5 Medium CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N.
Intel is providing a microcode update to mitigate GDS. No software changes are required to enable the mitigation. System administrators, application developers, and users should carefully consider the threat model applicable to their systems when deciding whether and where to mitigate GDS. Based on the environmental threat model, users may disable the GDS mitigation with options provided by operating system vendors (OSVs).
Intel is not aware of any instance of any of this vulnerability being exploited outside a controlled lab environment.
Malicious software may be able to infer data previously stored in vector registers used by either the same thread, or the sibling thread on the same physical core. These registers may have been used by other security domains such as other virtual machine (VM) guests, the operating system (OS) kernel, or Intel® Software Guard Extensions (Intel® SGX) enclaves. Note that no processors that support Intel® Trust Domain Extension (Intel® TDX) are affected by GDS.
Mitigation
Intel is releasing a microcode update which blocks transient results of gather instructions to prevent attacker code from observing speculative results of gather loads. The mitigation is enabled by default when the patch is loaded, and cross-thread exposure is mitigated even with hyperthreading enabled. The microcode update provides an MSR interface that allows software to opt-out of the mitigation.
On processors affected by GDS, if Intel SGX is enabled and hyperthreading is disabled, loading the updated microcode will mitigate any potential direct attacks using GDS against Intel SGX enclaves. If Intel SGX is not enabled or if hyperthreading is enabled, the mitigation will not be locked, and system software can choose to enable or disable the GDS mitigation. There will be an Intel SGX TCB Recovery for those Intel SGX-capable affected processors.
No processors that support Intel TDX are affected by GDS.
Refer to the 2022-2023 tab of the consolidated Affected Processors table: Gather Data Sampling column.
Affected Processors: Guidance for Security Issues on Intel® Processors
This table shows the impact of transient execution attacks (formerly speculative execution side channel methods) and select security issues on currently supported Intel products, disclosed in 2018-2021, including recommended mitigation where affected.
https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html]]></description>
		<content:encoded><![CDATA[<p>Gather Data Sampling / CVE-2022-40982 / INTEL-SA-00828<br />
<a href="https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/gather-data-sampling.html" rel="nofollow">https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/gather-data-sampling.html</a><br />
Key Takeaways<br />
•	Intel is providing a microcode update to mitigate GDS. No software changes are required to enable the mitigation.<br />
•	Users should carefully consider the threat model applicable to their systems when deciding whether and where to mitigate GDS.<br />
•	Intel is not aware of any instance of any of this vulnerability being exploited outside a controlled lab environment.<br />
•	Operating system vendors (OSVs) provide options to opt out of the GDS mitigation. </p>
<p>Gather Data Sampling (GDS) is a transient execution side channel vulnerability affecting certain Intel processors. In some situations when a gather instruction performs certain loads from memory, it may be possible for a malicious attacker to use this type of instruction to infer stale data from previously used vector registers. Similar to data sampling transient execution attacks like Microarchitectural Data Sampling (MDS), GDS may allow a malicious actor who can locally execute code on a system to infer the values of secret data which is otherwise protected by architectural mechanisms. GDS differs from the MDS vulnerabilities in both the method of exposure (which is limited to the set of gather instructions), and in the data exposed (stale vector register data only). Neither MDS nor GDS, by themselves, provide malicious actors the ability to choose which data is inferred using these methods.<br />
GDS is assigned CVE-2022-40982 CVSS Base Score 6.5 Medium CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N.<br />
Intel is providing a microcode update to mitigate GDS. No software changes are required to enable the mitigation. System administrators, application developers, and users should carefully consider the threat model applicable to their systems when deciding whether and where to mitigate GDS. Based on the environmental threat model, users may disable the GDS mitigation with options provided by operating system vendors (OSVs).<br />
Intel is not aware of any instance of any of this vulnerability being exploited outside a controlled lab environment.<br />
Malicious software may be able to infer data previously stored in vector registers used by either the same thread, or the sibling thread on the same physical core. These registers may have been used by other security domains such as other virtual machine (VM) guests, the operating system (OS) kernel, or Intel® Software Guard Extensions (Intel® SGX) enclaves. Note that no processors that support Intel® Trust Domain Extension (Intel® TDX) are affected by GDS.<br />
Mitigation<br />
Intel is releasing a microcode update which blocks transient results of gather instructions to prevent attacker code from observing speculative results of gather loads. The mitigation is enabled by default when the patch is loaded, and cross-thread exposure is mitigated even with hyperthreading enabled. The microcode update provides an MSR interface that allows software to opt-out of the mitigation.<br />
On processors affected by GDS, if Intel SGX is enabled and hyperthreading is disabled, loading the updated microcode will mitigate any potential direct attacks using GDS against Intel SGX enclaves. If Intel SGX is not enabled or if hyperthreading is enabled, the mitigation will not be locked, and system software can choose to enable or disable the GDS mitigation. There will be an Intel SGX TCB Recovery for those Intel SGX-capable affected processors.<br />
No processors that support Intel TDX are affected by GDS.<br />
Refer to the 2022-2023 tab of the consolidated Affected Processors table: Gather Data Sampling column.<br />
Affected Processors: Guidance for Security Issues on Intel® Processors<br />
This table shows the impact of transient execution attacks (formerly speculative execution side channel methods) and select security issues on currently supported Intel products, disclosed in 2018-2021, including recommended mitigation where affected.<br />
<a href="https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html" rel="nofollow">https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1810459</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Sun, 13 Aug 2023 07:07:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1810459</guid>
		<description><![CDATA[Fed-up Torvalds suggests disabling AMD’s &#039;stupid&#039; performance-killing fTPM RNG
Some Ryzen Linux machines still stumble along despite efforts to fix it all
https://www.theregister.com/2023/07/31/linus_torvalds_ftpm/]]></description>
		<content:encoded><![CDATA[<p>Fed-up Torvalds suggests disabling AMD’s &#8216;stupid&#8217; performance-killing fTPM RNG<br />
Some Ryzen Linux machines still stumble along despite efforts to fix it all<br />
<a href="https://www.theregister.com/2023/07/31/linus_torvalds_ftpm/" rel="nofollow">https://www.theregister.com/2023/07/31/linus_torvalds_ftpm/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1810458</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Sun, 13 Aug 2023 07:06:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1810458</guid>
		<description><![CDATA[Linux Creator Expresses “Frustration” Towards AMD’s fTPM Bugs, Calls To Disable Feature
https://wccftech.com/linux-creator-expresses-frustration-towards-amds-ftpm-bugs-calls-to-disable-feature/

AMD&#039;s fTPM issues are well-known in the industry, often causing system crashes and freezing. Linux&#039;s creator Linus Torvalds has expressed his disappointment towards the feature, labeling it a &quot;plague&quot; for the kernel.

AMD&#039;s fTPM Issues Have A Long History, Emerging With The Release of Windows 11

For a quick recap, Trusted Platform Module or TPM is a security check which has been made a necessity to be enabled for the latest version of Windows 11. While the intention behind this move is for the consumer&#039;s benefit, the feature brought several problems. The main problems that fTPM brought were random stuttering and lagging. Moreover, several users also experienced jittering and disruptions while gaming. While the problem did occur in the Intel platform, most of the issues were on AMD, which still persist today.]]></description>
		<content:encoded><![CDATA[<p>Linux Creator Expresses “Frustration” Towards AMD’s fTPM Bugs, Calls To Disable Feature<br />
<a href="https://wccftech.com/linux-creator-expresses-frustration-towards-amds-ftpm-bugs-calls-to-disable-feature/" rel="nofollow">https://wccftech.com/linux-creator-expresses-frustration-towards-amds-ftpm-bugs-calls-to-disable-feature/</a></p>
<p>AMD&#8217;s fTPM issues are well-known in the industry, often causing system crashes and freezing. Linux&#8217;s creator Linus Torvalds has expressed his disappointment towards the feature, labeling it a &#8220;plague&#8221; for the kernel.</p>
<p>AMD&#8217;s fTPM Issues Have A Long History, Emerging With The Release of Windows 11</p>
<p>For a quick recap, Trusted Platform Module or TPM is a security check which has been made a necessity to be enabled for the latest version of Windows 11. While the intention behind this move is for the consumer&#8217;s benefit, the feature brought several problems. The main problems that fTPM brought were random stuttering and lagging. Moreover, several users also experienced jittering and disruptions while gaming. While the problem did occur in the Intel platform, most of the issues were on AMD, which still persist today.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomi Engdahl</title>
		<link>https://www.epanorama.net/blog/2018/01/03/kernel-memory-leaking-intel-processor-design-flaw/comment-page-12/#comment-1810383</link>
		<dc:creator><![CDATA[Tomi Engdahl]]></dc:creator>
		<pubDate>Sat, 12 Aug 2023 11:42:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.epanorama.net/newepa/?p=62445#comment-1810383</guid>
		<description><![CDATA[Intel Releases a Patch for &#039;Downfall&#039; Vulnerability Affecting Billions of CPUs
There are no free lunches, though, so the fix for this bug comes with a performance penalty.
https://www.extremetech.com/internet/intel-releases-a-patch-for-downfall-vulnerability-affecting-billions-of

Intel has released a patch to plug a gaping hole in the security of older CPUs—specifically, those made from 2015 to 2019, aka Skylake to Tiger Lake. The vulnerability allowed a person sharing a computer with another person to steal &quot;high-value credentials&quot; such as passwords and encryption keys. Though most of us don&#039;t usually share a computer with another person, it&#039;s a standard scenario in cloud computing, with many clients accessing the same hardware simultaneously. Unfortunately, Intel&#039;s fix comes with a performance penalty.

The vulnerability affecting billions of Intel CPUs was discovered by Daniel Moghimi, who is a Senior Research Scientist at Google. According to the site Mr. Moghimi made for the bug, the vulnerability essentially allows sensitive data to move between two users sharing the same physical CPU cores, a common scenario in a cloud computing environment. It&#039;s due to a memory optimization feature in older Intel CPUs whereby internal hardware registers are inadvertently exposed to software, allowing a malicious actor to steal sensitive information from whoever is sharing the computer&#039;s resources. Intel states in its security bulletin that it&#039;s not aware of this attack being used outside of a &quot;controlled lab environment.&quot;]]></description>
		<content:encoded><![CDATA[<p>Intel Releases a Patch for &#8216;Downfall&#8217; Vulnerability Affecting Billions of CPUs<br />
There are no free lunches, though, so the fix for this bug comes with a performance penalty.<br />
<a href="https://www.extremetech.com/internet/intel-releases-a-patch-for-downfall-vulnerability-affecting-billions-of" rel="nofollow">https://www.extremetech.com/internet/intel-releases-a-patch-for-downfall-vulnerability-affecting-billions-of</a></p>
<p>Intel has released a patch to plug a gaping hole in the security of older CPUs—specifically, those made from 2015 to 2019, aka Skylake to Tiger Lake. The vulnerability allowed a person sharing a computer with another person to steal &#8220;high-value credentials&#8221; such as passwords and encryption keys. Though most of us don&#8217;t usually share a computer with another person, it&#8217;s a standard scenario in cloud computing, with many clients accessing the same hardware simultaneously. Unfortunately, Intel&#8217;s fix comes with a performance penalty.</p>
<p>The vulnerability affecting billions of Intel CPUs was discovered by Daniel Moghimi, who is a Senior Research Scientist at Google. According to the site Mr. Moghimi made for the bug, the vulnerability essentially allows sensitive data to move between two users sharing the same physical CPU cores, a common scenario in a cloud computing environment. It&#8217;s due to a memory optimization feature in older Intel CPUs whereby internal hardware registers are inadvertently exposed to software, allowing a malicious actor to steal sensitive information from whoever is sharing the computer&#8217;s resources. Intel states in its security bulletin that it&#8217;s not aware of this attack being used outside of a &#8220;controlled lab environment.&#8221;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
