JismIt would be a different story if that patch would bin applied by CPU micro code or BIOS fix, not Software / OS fix.

JismThat people actually believe, that a 'patch' will solve this thing, lol. Patch will be overwritten and your system is back to being vulnerable again. It takes some time for hackers to develop a serious exploit.


You sure? If a hacker would succesfully write his own patch to disable that patch, then that CPU goes back to doing normal thing again, making it vulnerable. He is right. The scale of Meltdown is easily underestimated. Every intel CPU is vulnerable. It would be a different story if that patch would bin applied by CPU micro code or BIOS fix, not Software / OS fix.

Manu_PTIf you have no problems by using a CPU at that constant risk, that´s up to you. I refuse to.

_JP_]please update the image to reflect that the issue happens on older chipsets and/or add more information, Ryzen seems not to be affected so far. As it stands, it is vague and creates FUD around which AMD products this is being affected, with reports so far pointing to K8-era hardware. It is enough that this is already happening with Intel CPUs..

Captain_TomThe Window Updates over the past year have been a complete nightmare for me. Doesn't matter if it's an AMD or Intel system.... At least one of my PC's breaks every major update.

The worst part is I cannot even decide I don't want a machine-breaking update! God we need an alternative to Windows so bad right now...

Captain_TomThe Window Updates over the past year have been a complete nightmare for me. Doesn't matter if it's an AMD or Intel system.... At least one of my PC's breaks every major update.

The worst part is I cannot even decide I don't want a machine-breaking update! God we need an alternative to Windows so bad right now...

64KI think MS has shifted the burden of QA and testing from themselves to their customers. Pretty damn lazy of them and what happened here is a result of that mindset.

ssdproAMD already confirmed their CPUs are vulnerable to variant 1 and variant 2. The internet trolls like to say AMD isn't vulnerable to variant 2 since AMD says "there is near zero risk". Near is not "no". All of this is near zero for all CPUs. RyZen is AMD's current product and this is their problem (bricking PCs). And yes, Intel sucks. Just being fair.

JismInstall W7 X64. And use it for another 2 years untill support ends up. By that time, linux and Wine is getting so accepted that you should be able to create an alternative OS easily. It's the same i'm doing. You cant tell how many computers every month get bricked due to failed updates.

_JP_Please, don't create confusion over this.

DeathtoGnomesif m$ is pointing fingers at anyone, intel paid them to point at AMD. #conspiracytheories

CasecutterThis... while btarunr continues to propagate the two (Intel/MS) as "holier-than-thou" and bashes AMD and their resent CPU product, when it appears it's not!

ssdproI have no idea what is so confusing to people here or if this is trolling or marketing stuff. This article has nothing to do with Intel. The problem is an MS update applied on some systems running AMD processors. AMD has even acknowledged it. See the update to the first post/story. I really don't think there is some massive Techpowerup/btarunr/Intel conspiracy here. The update applied to both Intel and AMD systems. Intel systems had no problem reports. AMD systems did. Same patch, different hardware. The variable was AMD hence the pic and title.

JB_GamerWhy the Ryzen image???

btarunr - pls remove it!!!

londisteWhat the patch does is tell CPU to clean out the valuable information from a place where hacker can access before the hacker gets to the point where he can access it.
When that information is not there, the CPU is not going to be able to read it.
No, it cannot.
What are you going back to, one of the Atoms? :)
For Meltdown, AMD and most of ARMs seem to be unaffected. For Spectre, here is a list:
forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128

Manu_PTMeltdown is not an issue that you can solve with a patch.

Meltdown paperThe KAISER patch by Gruss et al. [8] implements a stronger isolation between kernel and user space. KAISER does not map any kernel memory in the user space, except for some parts required by the x86 architecture (e.g., interrupt handlers). Thus, there is no valid mapping to either kernel memory or physical memory (via the direct-physical map) in the user space, and such addresses can therefore not be resolved. Consequently, Meltdown cannot leak any kernel or physical memory except for the few memory locations which have to be mapped in user space.
We verified that KAISER indeed prevents Meltdown, and there is no leakage of any kernel or physical memory.
Furthermore, if KASLR is active, and the few remaining memory locations are randomized, finding these memory locations is not trivial due to their small size of several kilobytes.

Meltdown paperAs hardware is not as easy to patch, there is a need for software workarounds until new hardware can be deployed. Gruss et al. [8] proposed KAISER, a kernel modification to not have the kernel mapped in the user space. This modification was intended to prevent side-channel attacks breaking KASLR [13, 9, 17]. However, it also prevents Meltdown, as it ensures that there is no valid mapping to kernel space or physical memory available in user space. KAISER will be available in the upcoming releases of the Linux kernel under the name kernel page-table isolation (KPTI) [25]. The patch will also be backported to older Linux kernel versions. A similar patch was also introduced in Microsoft Windows 10 Build 17035 [15]. Also, Mac OS X and iOS have similar features [22].

Although KAISER provides basic protection against Meltdown, it still has some limitations. Due to the design of the x86 architecture, several privileged memory locations are required to be mapped in user space [8]. This leaves a residual attack surface for Meltdown, i.e. , these memory locations can still be read from user space. Even though these memory locations do not contain any secrets, such as credentials, they might still contain pointers. Leaking one pointer can be enough to again break KASLR, as the randomization can be calculated from the pointer value.

Still, KAISER is the best short-time solution currently available and should therefore be deployed on all systems immediately. Even with Meltdown, KAISER can avoid having any kernel pointers on memory locations that are mapped in the user space which would leak information about the randomized offsets. This would require trampoline locations for every kernel pointer, i.e., the interrupt handler would not call into kernel code directly, but through a trampoline function. The trampoline function must only be mapped in the kernel. It must be randomized with a different offset than the remaining kernel. Consequently, an attacker can only leak pointers to the trampoline code, but not the randomized offsets of the remaining kernel. Such trampoline code is required for every kernel memory that still has to be mapped in user space and contains kernel addresses. This approach is a trade-off between performance and security which has to be assessed in future work.

londisteMeltdown paper seems to disagree with you:


You are technically correct that it does not fix the issue, it is a mitigation measure. However, it does effectively mitigate the problem to the degree where it is not feasible to use the vulnerability. The paper describes the situation further:

laszlowhat @Manu_PT try to explain is that current patch will become useless once the hackers(nsa) will manage to undo is effects and use the vulnerability again ... so we may have an endless release of patches(if hackers successful attack is discovered..) .... patching the previous patch without success as a soft patch can't fix a cpu architecture design which has a flaw (feature)...