All your chips belong to us! Security flaws puts most phones, computers at risk...

[railer]

https://www.reuters.com/article/us-c...-idUSKBN1ES1BO

Was wondering what you guys think about this. To early to tell? Some rumors online predict up to 30% drop in performance with a patch Looking forward to benchmarks comparison before and after.

[kromosto]

AMD shall use this.

[Charles Wirth]

Too early to tell the performance impact and the % effected with this exploit. I do know a bit about this exploit as I wrote this code back in 1984 to work on several machines including a DEC VAX 11/780 that they call "Meltdown" to cheat at text based games originally.

The line of code reads every memory address and outputs to the screen, printer, or file in ascii format.

In BASIC, you need a for next loop and the correct syntax to peek at memory and display in ASCII format. Lets say you want to display to the screen.

for x = 1 to 1000000; print chr$(peek(x)); next x

This would dump contents of what is in the memory of any device (including AMD) to the screen, I can > direct to a file name etc. AMD cannot claim they are immune.

How to deploy the fix without disrupting application is the real question, no one can estimate the performance impact if any to you being allowed to dumping a range of memory or not.

As for Spectre, I am not sure of yet.

[Metroid]

This is quite the case.

[StAndrew]

In other news AMD's stock is doing great.

[iddqd]

Too early to tell the performance impact and the % effected with this exploit. I do know a bit about this exploit as I wrote this code back in 1984 to work on several machines including a DEC VAX 11/780 that they call "Meltdown" to cheat at text based games originally.

The line of code reads every memory address and outputs to the screen, printer, or file in ascii format.

In BASIC, you need a for next loop and the correct syntax to peek at memory and display in ASCII format. Lets say you want to display to the screen.

for x = 1 to 1000000; print chr$(peek(x)); next x

This would dump contents of what is in the memory of any device (including AMD) to the screen, I can > direct to a file name etc. AMD cannot claim they are immune.

How to deploy the fix without disrupting application is the real question, no one can estimate the performance impact if any to you being allowed to dumping a range of memory or not.

As for Spectre, I am not sure of yet.

(presumably,) nobody writes games to hide their state in the kernel space; you can already trivially look at the memory owned by every single user-space program. The point of this attack is being able to read protected memory owned by the kernel. You still can't write to it (which would be truly disastrous), but you could probably recall the memory rowhammer attacks that were published a few years ago? Once you discover a juicy bit of kernel-space memory (perhaps storing the address of memory to protect), you can rowhammer away at it at your leisure, eventually gaining write access over kernel memory too.

Protected memory is being 'read' (really, its contents are being indirectly inferred) by cleverly abusing architectural flaws that were designed to get more performance. AMD, of course, claims that since its architecture is different, it must be immune to the attack - which is probably true for this particular attack. More likely, of course, is that the attack approach can work on AMD CPUs too, just no-one has discovered how quite yet.

[kromosto]

(presumably,) nobody writes games to hide their state in the kernel space; you can already trivially look at the memory owned by every single user-space program. The point of this attack is being able to read protected memory owned by the kernel. You still can't write to it (which would be truly disastrous), but you could probably recall the memory rowhammer attacks that were published a few years ago? Once you discover a juicy bit of kernel-space memory (perhaps storing the address of memory to protect), you can rowhammer away at it at your leisure, eventually gaining write access over kernel memory too.

Protected memory is being 'read' (really, its contents are being indirectly inferred) by cleverly abusing architectural flaws that were designed to get more performance. AMD, of course, claims that since its architecture is different, it must be immune to the attack - which is probably true for this particular attack. More likely, of course, is that the attack approach can work on AMD CPUs too, just no-one has discovered how quite yet.

I believe this exploit is because of ME.

[railer]

Too early to tell the performance impact and the % effected with this exploit. I do know a bit about this exploit as I wrote this code back in 1984 to work on several machines including a DEC VAX 11/780 that they call "Meltdown" to cheat at text based games originally.

The line of code reads every memory address and outputs to the screen, printer, or file in ascii format.

In BASIC, you need a for next loop and the correct syntax to peek at memory and display in ASCII format. Lets say you want to display to the screen.

for x = 1 to 1000000; print chr$(peek(x)); next x

This would dump contents of what is in the memory of any device (including AMD) to the screen, I can > direct to a file name etc. AMD cannot claim they are immune.

How to deploy the fix without disrupting application is the real question, no one can estimate the performance impact if any to you being allowed to dumping a range of memory or not.

As for Spectre, I am not sure of yet.

This was a very interesting post.

They are keeping tabs on performance hit for now. Looks like chip companies were alerted about this back in June.

[railer]

(presumably,) nobody writes games to hide their state in the kernel space; you can already trivially look at the memory owned by every single user-space program. The point of this attack is being able to read protected memory owned by the kernel. You still can't write to it (which would be truly disastrous), but you could probably recall the memory rowhammer attacks that were published a few years ago? Once you discover a juicy bit of kernel-space memory (perhaps storing the address of memory to protect), you can rowhammer away at it at your leisure, eventually gaining write access over kernel memory too.

Protected memory is being 'read' (really, its contents are being indirectly inferred) by cleverly abusing architectural flaws that were designed to get more performance. AMD, of course, claims that since its architecture is different, it must be immune to the attack - which is probably true for this particular attack. More likely, of course, is that the attack approach can work on AMD CPUs too, just no-one has discovered how quite yet.

Not sure about discovered it may not have been released or leaked yet. The WPA2 was secured too, until it wasn't.

[Charles Wirth]

It was an example of reading memory, not arming a targeted payload. I just started peeking at memory very early.

The problem is data centers and VM space having someone dumping protected memory to a file, the advantage of doing this to a data center is taking a snapshot of all the VM's.

It comes down to shared kernel mapping and it appears someone found where it may be unprotected or the chipset issues the command looking directly before it is encrypted.

Unlike my example, this Meltdown code would have to be targeted for its victim OS and hardware config based on various reports.

[drmrlordx]

AMD has claimed publicly that their chips are immune to Meltdown but vulnerable to at least one form of the Spectre attack (the other poses 'near zero risk').

Patching against Spectre allegedly comes with no real performance hit.

Patching against Meltdown is a different matter entirely.

Until we see the combined force of OS kernel patches AND microcode updates, we won't know the full performance impact of the changes necessary to mitigate both flaws. Google claims they have their own way to patch against the vulnerability that they've used internally for quite awhile which may work out better than fixes like KTPI. Though honestly I don't know if their technique ('Retpoline') and KTPI are mutually exclusive.

[iddqd]

It was an example of reading memory, not arming a targeted payload. I just started peeking at memory very early.

The problem is data centers and VM space having someone dumping protected memory to a file, the advantage of doing this to a data center is taking a snapshot of all the VM's.

I see - I misunderstood your post. I guess you could look at what all the other VMs are doing on the machine, I hadn't thought of that. All the cloud service providers are going to freak out over this, of course, but snooping on what people's VMs are doing will likely yield absolutely nothing of interest.