News AMD 'Zenbleed' Bug Allows Data Theft From Zen 2 Processors, Patches Released

[bit_user]

Maybe this is where anti-virus software or ad-malware software can help.

That's questionable. The "spy" code is going to be running one or more threads probably nonstop, if the attacker wants to get as much information as possible. Maybe anti-malware can spot problematic Javascript code, but I wouldn't count on it.

So if you have decent security, I guess or hope everyone will be okay.

Anyone who's really worried should probably disable SMT, until they have a proper mitigation installed.

For people that must have great security to comply with laws. Then this is an issue they must resolve for compliance reasons.

If you run systems handling lots of sensitive or high-value information, disabling SMT on the host is always a prudent thing to do.

 

[zx128k]

The CPU alredy has a secure processor, the issue is people are able to get around the physical seperation of data. Security is no longer just an application level requirement, but a processor level requirement as well.

One of the big ways to protect data is encryption.

Also Anti-virus software does indeed stop problematic javascript. Disabling SMT is a big performance hit to take. Its different with games (Ryzen 9 3900X, SMT ON vs. SMT OFF, 36 Game Benchmark) its not a big deal if you have many cores but people report, "30-40% lower cinnebench scores and 3d mark score".

Making sure there is enough security for compliance reasons may not require turning off SMT. The work load may require SMT for performance reasons.

Security systems are designed to deal with failures at some points. An attack on one PC system wont affect network firewalls or other security features. Servers run only the code that is veted to be run on them. There will never be code from an outside source run on them. Data is encryption at all times, even in memory. The server processes requests in one way and there is no code passed from client to server which can be executed.

Its hard to attack a server with this attack because it wont run any code from outside the server. If a computer on the network becomes infected and starts acting strange. Deep packet inspection will see the problem in the packets sent across the network and block the PC from the network. Also if reguests for server data is outside of the norn, then there can be an alarm or the traffic can be blocked.

You don't have to disable SMT on the server as code on the server is veted and there is no way to get outside code to execute. The server ifself cant access the internet, the devices that can access the internet request information from the server. This can be a web server or local network client.

So how do you work from home, if you need access. Well you use a VPN and that gets you inside the corperate network.

There are layers of security so one failure won't cause everything to come down like a house of cards.

With the virus scanning side of things. The stuff you download is sent to a proxy and passes through firewalls. It gets scanned before it reaches the client and blocked. Javascript can be removed. The client anti-virus is just a last line of defence.

There are also lots of areas were this bug could cause issues for security as well. There you may need to take action.

 

[bit_user]

One of the big ways to protect data is encryption.

Be careful doling out generic advice, in the context of a specific problem. Encryption won't protect you against this vulnerability, because the leakage occurs in the CPU registers that are working with (mostly) unencrypted data.

Security systems are designed to deal with failures at some points. An attack on one PC system wont affect network firewalls or other security features. Servers run only the code that is veted to be run on them. There will never be code from an outside source run on them.

If someone behind a firewall has their password or access keys stolen via their web browser, then you don't actually need the firewall or server itself to be directly exploited.

You don't have to disable SMT on the server as code on the server is veted and there is no way to get outside code to execute.

You'd better know that no VMs hosted on the same hardware are vulnerable, then. Either that, or the hypervisor must adhere to a policy like I mentioned of not scheduling threads from two different VMs on the same CPU core. I don't know if that's something hypervisors do, or how common it is to enable that feature if it is.

If you're running your own local server, you can have that kind of visibility. In the cloud, I'm not so sure. Maybe you can rent an entire machine instance, to ensure it's not being shared with anything else. That's an expensive way to go, however.

Then again, we know the EPYC patch is already out, so these are just generic principles for managing VMs handling secure data.

There are layers of security so one failure won't cause everything to come down like a house of cards.

I don't mean to sound alarmist, but we also shouldn't be too complacent. The main risk of these kinds of exploits is theft of passwords, encryption keys, and access details. Once a hacker has the keys to your kingdom, all bets are off. I'm not saying that's trivial to pull off, but that's the risk and it's very hard to completely mitigate.

 

[jeremyj_83]

hypervisor must adhere to a policy like I mentioned of not scheduling threads from two different VMs on the same CPU core. I don't know if that's something hypervisors do, or how common it is to enable that feature if it is.

When the initial side-channel issues were found with Intel, this was a mitigation for VMware hypervisors. You could either turn off SMT or introduce security boundaries. I did this for all of my Intel hosts. https://kb.vmware.com/s/article/67577

 

[bit_user]

When the initial side-channel issues were found with Intel, this was a mitigation for VMware hypervisors. You could either turn off SMT or introduce security boundaries. I did this for all of my Intel hosts. https://kb.vmware.com/s/article/67577

Thanks!

@rluker5 , I think we were discussing this.

 

[domih]

Im still on a 2 year old BIOS. Im not upgrading. Ya, my PC is vulnerable, to who? The random guy that's going to pick me out of a billion people and somehow know that I have a Zen 2 chip. Ya, these vulnerabilities exist, but in practice they are completely irrelevant, unless your a big datacenter/big company with sensetive data. A home PC gamer shouldn't be worried

I understand why you think so but this is an assumption which has been debunked again and again. Security (on the wrong side of the law) has been a professional and commercial industry for quite some time now. Hackers do not care about who you are, they are after your PC as a compute resource and aim at monetizing it.

See: https://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/

 

[Hartemis]

Processors and computer systems already have dedicated security enclaves. Examples include AMD PSP, Intel Management Engine, ARM TrustZone, and Apple T2.

This is security modules and co-processors. I mean, x86 microarchitecture implemented with security in mind, not performance. And without risky optimizations, like speculation, SMT and others.

Intel's E-Cores doesn't have SMT. They are great starting point for that. They can be derived to S-Core, while the E-Cores remain for multi-threads tasks and efficiency.
Remain to adapt the Thread Director, Operating Systems and softwares, to be aware of that specificity.
And AMD could experiment disabling features, as by bit_user suggests, since they don't want hybrid architectures.

Like Intel's infamous TSX?

Yes, I was thinking cpu instructions like that. But the bit_user's proposal about system call is best.

 

[Hartemis]

You'd better know that no VMs hosted on the same hardware are vulnerable, then. Either that, or the hypervisor must adhere to a policy like I mentioned of not scheduling threads from two different VMs on the same CPU core. I don't know if that's something hypervisors do, or how common it is to enable that feature if it is.

These days I've heard that this is common practice with some VM providers, at least for performance reasons. To be sure of selling VMs with all the performance of a physical core, and not VMs that share their core with another VM.

SMT at least for lower core counts does tend to provide some measurable benefits across a range of workloads while the main downside of having Bergamo (Zen 4C) with SMT is that there could end up being some public cloud service providers that leverage SMT threads as part of their vCPU rating and advertising. At least from some of the major cloud service providers in recent years we've seen them leverage AMD EPYC servers with SMT disabled so each vCPU is backed by a physical CPU core. SMT off can also be better in the name of security.

https://www.phoronix.com/review/amd-epyc-9754-smt

 

[bit_user]

These days I've heard that this is common practice with some VM providers, at least for performance reasons. To be sure of selling VMs with all the performance of a physical core, and not VMs that share their core with another VM.

Intel Xeons have some QoS features designed to address such concerns.

What's interesting about virtualized workloads is that if it's not a realtime task, then you don't need whole CPUs. Instead, it's good enough to have a share of a CPU and pay just for what you use. I'm not saying that's how they're actually billed or managed, but you could.

 

[zx128k]

Be careful doling out generic advice, in the context of a specific problem. Encryption won't protect you against this vulnerability, because the leakage occurs in the CPU registers that are working with (mostly) unencrypted data.


If someone behind a firewall has their password or access keys stolen via their web browser, then you don't actually need the firewall or server itself to be directly exploited.


You'd better know that no VMs hosted on the same hardware are vulnerable, then. Either that, or the hypervisor must adhere to a policy like I mentioned of not scheduling threads from two different VMs on the same CPU core. I don't know if that's something hypervisors do, or how common it is to enable that feature if it is.

If you're running your own local server, you can have that kind of visibility. In the cloud, I'm not so sure. Maybe you can rent an entire machine instance, to ensure it's not being shared with anything else. That's an expensive way to go, however.

Then again, we know the EPYC patch is already out, so these are just generic principles for managing VMs handling secure data.


I don't mean to sound alarmist, but we also shouldn't be too complacent. The main risk of these kinds of exploits is theft of passwords, encryption keys, and access details. Once a hacker has the keys to your kingdom, all bets are off. I'm not saying that's trivial to pull off, but that's the risk and it's very hard to completely mitigate.

You need a key fob to access firewalls and all devices on the network. You can have a user name and password and it will get you nowhere. You have to get a valid security key fob for the correct number at login (each type on netork devices have their own key fob, switches/routers and firewards etc). Also network device access are on the out of band part of the network. This can only be accessed by the networking team on the corporate network.

Security is designed with loss of login details in mind. The end user doesn't get the trust to really leak data. Say someone got passed all this and start downloading a large volume of data from the server across the network? They would get flagged for an unusual access pattern to the server and then blocked from network access.

On the client side. You can even get documents like word etc that will become unreadable once removed from the corporate network. That you have to be the right user to access the document and read it. This way data that makes its way off the network is protected. Breaking the security on the file means you have to have the login of a user that can download the decryption key from the server. A server you can only access if you are within the corporate network and have the right user details to access. Admin access wont give you access, only the right persons login details. Then its will expire within x days deleting the document.

 

[hotaru.hino]

This is security modules and co-processors. I mean, x86 microarchitecture implemented with security in mind, not performance. And without risky optimizations, like speculation, SMT and others.

Intel's E-Cores doesn't have SMT. They are great starting point for that. They can be derived to S-Core, while the E-Cores remain for multi-threads tasks and efficiency.
Remain to adapt the Thread Director, Operating Systems and softwares, to be aware of that specificity.
And AMD could experiment disabling features, as by bit_user suggests, since they don't want hybrid architectures.

I'm against adding an application core purely for security because well, just use the existing security processor. That's what it's there for. In addition, it adds complexity to the system, which tends to make things less secure because 1. there's more points of an attack and 2. the cognitive load in understanding how the system works increases, making it less likely they'll be able to spot any weaknesses.

I don't believe that there's an inherent security issue with SMT, speculative execution, branch prediction, or other techniques. The problem is that sensitive data is mixed with non-sensitive data. It's like there's nothing inherently wrong with sharing your computer with a stranger, but if you want your data secured, you shouldn't be putting it (as much as you can) on that computer. If your data isn't in the same space as someone who has access to the machine, then there's a near zero chance of a sensitive data leak.

I would propose then if you want a "secure" environment that at least the register file, L1 cache, and L2 cache are partitioned by hardware thread and in every context switch they're flushed.

 

[bit_user]

I'm against adding an application core purely for security because well, just use the existing security processor. That's what it's there for.

No, it's not for application use. It's there for the OS or hypervisor.

I don't believe that there's an inherent security issue with SMT, speculative execution, branch prediction, or other techniques.

In theory, you could implement them without any leakage. In practice, the track record hasn't been a good one.

I would propose then if you want a "secure" environment that at least the register file, L1 cache, and L2 cache are partitioned by hardware thread and in every context switch they're flushed.

If you had hard allocations between cache slices and threads, then you'd need a lot more cache for the same performance we have today. Not only that, but every communication between threads would require a full DRAM access, which would kill multithreaded performance, in most cases.

Finally, calls into the kernel typically work/act like context switches. Requiring cache flushes (as there have been some mitigations that do) would add substantial overhead to them, and it would further tax thread communication and synchronization.

 

[hotaru.hino]

No, it's not for application use. It's there for the OS or hypervisor.

Then use the secure enclave co-processor, that's what it's there for.

In theory, you could implement them without any leakage. In practice, the track record hasn't been a good one.

If you had hard allocations between cache slices and threads, then you'd need a lot more cache for the same performance we have today. Not only that, but every communication between threads would require a full DRAM access, which would kill multithreaded performance, in most cases.

Finally, calls into the kernel typically work/act like context switches. Requiring cache flushes (as there have been some mitigations that do) would add substantial overhead to them, and it would further tax thread communication and synchronization.

So I ask again: how do you quash the fact that at some point in the execution pipeline, data from multiple processes and/or threads are close to each other and the CPU has to assume the access is valid?

The fundamental problem with transient execution bugs is the idea that the way CPUs are currently designed break the security model of what's expected out of applications. Applications for any given modern computer system are going to believe they own the entire system (or at least what's exposed to them). So the security model has been to isolate every application from each other. But that's a problem considering we want applications to share data all the time or we want applications to reuse the same things that other applications use to avoid excessive memory consumption.

As long as one process's data resides in the same locality of another and the CPU has undefined execution paths (for which far outnumber the number of defined execution paths), the possibility of unintended data leakage remains. You may as well ask how do we keep Top Secret documents together with freely accessible public documents and 100% prevent a classified information leak.

But a simple fact remains: our widely used, modern computer systems still act like an advanced PDP-11.

 

[bit_user]

Then use the secure enclave co-processor, that's what it's there for.

The only search hits on that I can find are about something inside the iPhone.

So I ask again: how do you quash the fact that at some point in the execution pipeline, data from multiple processes and/or threads are close to each other and the CPU has to assume the access is valid?

Well, like I've been saying, you could restrict the CPU to allow only threads from the same process to share a core.

I never claimed to have the ultimate solution for stopping all side-channel attacks. I did think the idea of temporarily putting a core in "secure mode" was interesting. That could also include giving it a dedicated cache allocation and flushing it afterwards.

 

[JamesJones44]

Then use the secure enclave co-processor, that's what it's there for.

The Secure Enclave is really meant for running actions outside of the main process (encrypting, decrypting, biometric authentication, etc.). It's not designed to only process instructions that contain sensitive information (despite the description making it sound like it works like that).

In the case where a general instruction contained a piece of sensitive information and was leaked via cache, thread sharing, etc. it wouldn't protect a user from that type of attack.

 

[rluker5]

In the imagined scenario, I think there'd just be an API call to tell the OS "Hey, I'm entering a sensitive section". At that point, it blocks the thread until you're running on a core configured for maximum security, migrating the thread if necessary. When you're done, just tell the OS with a corresponding call. The OS could manage whatever needs to happen at the hardware level. Like, if there's a switch to disable speculation and branch prediction, the OS could toggle it. If the thread needs to be migrated, or a peer needs to be suspended, that could happen too.

When you put it like that it sounds like a great idea. They could even give it a hotkey, like windows+tab so concerned users could make the decision to temporarily choose to lose a bit of performance in the name of security. I'd even go so far as to let Windows suspend any and all processes not in the foreground or on a system whitelist. It doesn't seem like that much more of a necessary hassle than UAC.

Ideally though, the OS would enforce the security automatically when the agreed API calls for it. To protect the masses of home users.

 

[bit_user]

Ideally though, the OS would enforce the security automatically when the agreed API calls for it. To protect the masses of home users.

The OS could definitely have hooks into common encryption libraries which enables it to provide some degree of protection over that part, but it wouldn't know when the application is handling sensitive decrypted data.

There are some programming languages which can track the flow of sensitive or unsanitized data by carrying some additional metadata. Such a language could automatically enable "secure operation" for threads handling decrypted information.

 

[Hartemis]

As long as we aren't able to discern which specific sub-sections of a program are sensitive. linux distributions could define a "red-list" of applications that should be run on secure-core or mode. Extended by the user.