row hammer...

[server]

https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Lasse Langwadt Christensen]

mandag den 31. august 2020 kl. 17.30.41 UTC+2 skrev jla...@highlandsniptechnology.com:

https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

afaiu it is not an x86 problem it is a RAM problem and has been
demonstrated on ARM devices too

 

[Joe Gwinn]

On Mon, 31 Aug 2020 08:30:30 -0700, jlarkin@highlandsniptechnology.com
wrote:

https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

It is not clear that this is an x86 problem, as DRAM is used
universally, and the method depends on DRAM implementation.

Joe Gwinn

 

[server]

On Mon, 31 Aug 2020 11:46:48 -0400, Joe Gwinn <joegwinn@comcast.net>
wrote:

On Mon, 31 Aug 2020 08:30:30 -0700, jlarkin@highlandsniptechnology.com
wrote:


https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

It is not clear that this is an x86 problem, as DRAM is used
universally, and the method depends on DRAM implementation.

Joe Gwinn

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

\"The second exploit revealed by Project Zero runs as an unprivileged
Linux process on the x86-64 architecture, exploiting the row hammer
effect to gain unrestricted access to all physical memory installed in
a computer.\"

We live in the Dark Ages of computing.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[John Doe]

jlarkin@highlandsniptechnology.com wrote:

> That\'s amazing. If x86 can possibly do something wrong, it does.

\"“Rowhammer” is a problem with some recent DRAM devices in which
repeatedly accessing a row of memory can cause bit flips in adjacent
rows.\"

That\'s not a CPU problem.

 

[Tim Williams]

I hope no one tells you about the Spectre and Meltdown family of attacks...
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
\"Spectre has been shown to work on Intel, AMD, ARM-based, and IBM
processors\"

You\'re very out of touch. Row hammer has been known basically since DRAM
was invented..? Absolutely nothing to do with x86. Not that anyone runs
x86 anymore anyway, x64 is where it\'s at for desktops and servers. Or ARM,
or a couple of other things mostly for special application (only time will
tell if say, Apple returns to POWER, or if RISC-V gains substantial market
share, or..).

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/

<jlarkin@highlandsniptechnology.com> wrote in message
news:go5qkfdbnifk2bdhq2ul78qjk0nmct2bb9@4ax.com...

https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[server]

On Mon, 31 Aug 2020 12:04:28 -0500, \"Tim Williams\"
<tiwill@seventransistorlabs.com> wrote:

I hope no one tells you about the Spectre and Meltdown family of attacks...
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
\"Spectre has been shown to work on Intel, AMD, ARM-based, and IBM
processors\"

You\'re very out of touch.

OK, bye.



--

John Larkin Highland Technology, Inc

Science teaches us to doubt.

Claude Bernard

 

[Don Y]

On 8/31/2020 8:46 AM, Joe Gwinn wrote:

On Mon, 31 Aug 2020 08:30:30 -0700, jlarkin@highlandsniptechnology.com
wrote:


https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

It is not clear that this is an x86 problem, as DRAM is used
universally, and the method depends on DRAM implementation.

DRAM has always had potential \"issues\" with disturbances.

We used some 1Kb (that\'s \'b\', not \'B\'!) DRAMs in the early 70\'s to
replace core (REAL core!) and had to evaluate and address means
of mitigating.

For years, we would study the internal structure of candidate devices
to determine the \"right\" way to test them (to ferret out the most
elusive failures).

Nowadays, read and write disturb on FLASH represent a similar bane.

But, many of these issues can be addressed with compiler rework
and the awareness of the developer. (which is unfortunate) But,
as more \"smarts\" get moved into the silicon... <shrug> OTOH,
that\'s the IDEAL place to mitigate the problem -- though at
some cost in design complexity!

 

[Dave Platt]

In article <go5qkfdbnifk2bdhq2ul78qjk0nmct2bb9@4ax.com>,
<jlarkin@highlandsniptechnology.com> wrote:

https://en.wikipedia.org/wiki/Row_hammer

That\'s amazing. If x86 can possibly do something wrong, it does.

The fundamental vulnerabilities here are those of the DDR DRAM, not
the x86 architecture. There are some ways in which it\'s easier to
exploit on x86, but (as the article you cited points out) it\'s quite
possible to exploit it in an architecture-independent way.

The article also points out that it has been exploited on Android
smart-phones, which are almost all ARM-based.

There are (independently of this) a bunch of other sorts of
information-leak exploits (typically speculative-fetch) which are
specific to Intel\'s 64-bit microarchitecture; apparently AMD\'s
microarchitectures for that same instruction set are immune to mahy of
these.

 

[Don Y]

On 8/31/2020 9:29 AM, jlarkin@highlandsniptechnology.com wrote:

On Mon, 31 Aug 2020 11:46:48 -0400, Joe Gwinn <joegwinn@comcast.net
wrote:

On Mon, 31 Aug 2020 08:30:30 -0700, jlarkin@highlandsniptechnology.com
wrote:


https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

It is not clear that this is an x86 problem, as DRAM is used
universally, and the method depends on DRAM implementation.

Joe Gwinn

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

No. The exploit can be applied to other processors, as well.

\"The second exploit revealed by Project Zero runs as an unprivileged
Linux process on the x86-64 architecture, exploiting the row hammer
effect to gain unrestricted access to all physical memory installed in
a computer.\"

We live in the Dark Ages of computing.

Makes you wonder how many of those EDA tools you use are lying to you! :>

OTOH, REALLY makes you wonder how often the machine is NOT executing the
code (and machine state) \"as prescribed\" -- yet APPEARING to produce
good results!

 

[John Doe]

dplatt@coop.radagast.org (Dave Platt) wrote:

jlarkin@highlandsniptechnology.com> wrote:

https://en.wikipedia.org/wiki/Row_hammer

That\'s amazing. If x86 can possibly do something wrong, it does.

The fundamental vulnerabilities here are those of the DDR DRAM, not
the x86 architecture.

Pretty sure he\'s gotten the drift by now... lol

 

[Rob]

jlarkin@highlandsniptechnology.com <jlarkin@highlandsniptechnology.com> wrote:

On Mon, 31 Aug 2020 11:46:48 -0400, Joe Gwinn <joegwinn@comcast.net
wrote:

On Mon, 31 Aug 2020 08:30:30 -0700, jlarkin@highlandsniptechnology.com
wrote:


https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

It is not clear that this is an x86 problem, as DRAM is used
universally, and the method depends on DRAM implementation.

Joe Gwinn

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

DRAM without ECC essentially is only suitable for toys.
All serious machines using DRAM have ECC on top of it.

 

[Dave Platt]

In article <slrnrkqli8.pap.nomail@xs9.xs4all.nl>,
Rob <nomail@example.com> wrote:

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

DRAM without ECC essentially is only suitable for toys.
All serious machines using DRAM have ECC on top of it.

By that criterion, probably 90+ percent PCs used in homes and business
offices in the United States are toys.

It is (unfortunately) relatively uncommon for PC motherboards to
support ECC on the DRAM. Very few consumer-grade boards do, and (I
believe) only a minority of business-grade boards by the Big Makers.
One tends to find ECC only in servers, or in specially-ordered
workstations.

Although you may be able to put an ECC DIMM/SODIMM in a standard
motherboard, and have the computer boot OK, and maybe even identify
the memory as being ECC-equipped, it won\'t actually do you any good...
the common chipsets usually don\'t perform ECC, and even if they do the
motherboard is sometimes built without the additional memory-bus
traces required to connect the additional IC to the chipset.

As I understand it, this is mostly a question of cost and performance.
Supporting ECC requires more chips on the DIMM, it requires more
traces on the board, and it slows down memory access slightly. As a
result, there\'s a tradeoff between reliability, and performance-per-
dollar.

It was only fairly recently that I found a home-PC motherboard that I
liked, which had ECC support (one of the TaiChi family). It cost more to
equip the board with ECC-enabled DIMMs but I felt it was worth it in the long
run.

 

[Don Y]

On 8/31/2020 1:46 PM, Dave Platt wrote:

In article <slrnrkqli8.pap.nomail@xs9.xs4all.nl>,
Rob <nomail@example.com> wrote:

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

DRAM without ECC essentially is only suitable for toys.
All serious machines using DRAM have ECC on top of it.

By that criterion, probably 90+ percent PCs used in homes and business
offices in the United States are toys.

A much more significant problem is the relatively infrequent support
for ECC in embedded devices -- many of which now run bloated OSs
to host their (bloated?) applications.

A manufacturer often has more margin to accommodate features like
ECC in a (relatively) expensive PC than in a $100 \"appliance\".

It is (unfortunately) relatively uncommon for PC motherboards to
support ECC on the DRAM. Very few consumer-grade boards do, and (I
believe) only a minority of business-grade boards by the Big Makers.
One tends to find ECC only in servers, or in specially-ordered
workstations.

As I understand it, this is mostly a question of cost and performance.
Supporting ECC requires more chips on the DIMM, it requires more
traces on the board, and it slows down memory access slightly. As a
result, there\'s a tradeoff between reliability, and performance-per-
dollar.

Also, PCs tend to have \"users\" sitting in front of them. So, if
something goes wonky, the user can do something about it (even if
that means reissuing a command, restarting an application or rebooting
the machine).

Ask yourself how various products *handle* errors -- even when they
are INFORMED of their presence (i.e., what do you do?? when are there
\"too many\" errors? How do you mitigate this once you\'ve encountered it?
How do you proactively minimize that scenario? If you\'re using SECDEC
ECC and seeing errors, how confident are you that there are not other
errors occurring that you\'re NOT \"seeing\"?)

 

[Don Y]

On 8/31/2020 2:49 PM, Don Y wrote:

Ask yourself how various products *handle* errors -- even when they
are INFORMED of their presence (i.e., what do you do?? when are there
\"too many\" errors? How do you mitigate this once you\'ve encountered it?
How do you proactively minimize that scenario? If you\'re using SECDEC

Grrr... SECDEC should obviously be SECDED.

ECC and seeing errors, how confident are you that there are not other
errors occurring that you\'re NOT \"seeing\"?)

 

[Sergey Kubushyn]

Dave Platt <dplatt@coop.radagast.org> wrote:

In article <slrnrkqli8.pap.nomail@xs9.xs4all.nl>,
Rob <nomail@example.com> wrote:

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

DRAM without ECC essentially is only suitable for toys.
All serious machines using DRAM have ECC on top of it.

By that criterion, probably 90+ percent PCs used in homes and business
offices in the United States are toys.

It is (unfortunately) relatively uncommon for PC motherboards to
support ECC on the DRAM. Very few consumer-grade boards do, and (I
believe) only a minority of business-grade boards by the Big Makers.
One tends to find ECC only in servers, or in specially-ordered
workstations.

Although you may be able to put an ECC DIMM/SODIMM in a standard
motherboard, and have the computer boot OK, and maybe even identify
the memory as being ECC-equipped, it won\'t actually do you any good...
the common chipsets usually don\'t perform ECC, and even if they do the
motherboard is sometimes built without the additional memory-bus
traces required to connect the additional IC to the chipset.

As I understand it, this is mostly a question of cost and performance.
Supporting ECC requires more chips on the DIMM, it requires more
traces on the board, and it slows down memory access slightly. As a
result, there\'s a tradeoff between reliability, and performance-per-
dollar.

It was only fairly recently that I found a home-PC motherboard that I
liked, which had ECC support (one of the TaiChi family). It cost more to
equip the board with ECC-enabled DIMMs but I felt it was worth it in the long
run.

My Dell T5500 workstations (I have 5 at home and several more at different
places I do work for) are all ECC. 12 physical cores, 72Gbytes RAM. Those
are not servers although built like tanks, very well made machines. Just
don\'t buy cheap \"latest and greatest\" crap.

T5500 is kinda old but it has everything one might need (dunno about stupid
gamers though) and it more than adequate for any engineering job. And it
still has not just those fancy PCIe that is probably bigger crime against
humanity than USB and Java combined, but also good old PCI-X and PCI. It is
quite unless working with full load on all 12 cores, very well suitable for
home use.

The good thing is you can get a fully loaded one for less than $1K from
eBay. There are tons of spare parts too; DRAM (registered ECC) is relatively
cheap and abundant so what else to ask for? Just get yourself a good Nvidia
Quadro video card (K4200 is probably the best) and don\'t try to use the
fastest 3.6GHz processors (X5680) as those just slightly faster than the
best 3.07GHz X5675 but draw two times more power and thus generate way more
heat and fan noise.

Highly recommended And there is a bigger brother, T7500 that allow one to
put even more RAM if 72Gbytes is not enough but those are not as common as
T5500.

---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************

 

[Don Y]

On 8/31/2020 2:55 PM, Sergey Kubushyn wrote:

Highly recommended And there is a bigger brother, T7500 that allow one to
put even more RAM if 72Gbytes is not enough but those are not as common as
T5500.

I ran a herd of T7400s and T7500s, here, but scrapped them in favor of Z800s.
The Dell boxes were *huge* (the Z800s are only slightly smaller) and difficult
to man-handle (they have feet on the bottom that dig into the carpet pile
so you have to set them on a wooden plank if you want to be able to SLIDE
them around -- \"lifting\" is essentially out of the question! The Z800\'s
are considerably easier to move around and seem to be more ruggedly built.
(they also have built in \"handles\" for those times when you want to lift them)
E.g., the flimsy side panel on the Dells was always binding when trying
to remove/replace; by contrast, the heavier gauge panel on the Z800 comes
off and on easily.

They\'re comparable in performance (Xeons) and roughly the same in terms
of acoustic noise. The Dell boxes will support *4* internal drives -- in
addition to the front-accessible bays. I think each has 1100W power supplies
though the Z800s is a really proprietary package (I rescued 3 spares \"just
in case\"). The Dell power supplies aren\'t going to be cheaply replaced
*if* they develop faults.

[It seems like all of my machines have oddball power supplies! E.g., the
SB2000\'s power supply is bigger than most PCs!]

I find use for the extra PCIe slots -- SAS controller, USB3 add-in -- plus
the display slots. The only PCI (-X) cards that I use are SCSI HBAs and
I don\'t need those in every machine.

None of the machines mentioned will push the performance limits available,
today. But, the idea of twiddling your thumbs WAITING for a machine suggests
you don\'t have enough OTHER things to do! :> I\'ve six of the Z800s in my
small office so I can easily swivel my chair and start work on another
task on another workstation.

Oh, and at $10/machine, I figured I couldn\'t even afford to buy drive sleds
for a newer box! :>

 

[Mat Nieuwenhoven]

On Mon, 31 Aug 2020 13:46:58 -0700, Dave Platt wrote:

In article <slrnrkqli8.pap.nomail@xs9.xs4all.nl>,
Rob <nomail@example.com> wrote:

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

DRAM without ECC essentially is only suitable for toys.
All serious machines using DRAM have ECC on top of it.

By that criterion, probably 90+ percent PCs used in homes and business
offices in the United States are toys.

It is (unfortunately) relatively uncommon for PC motherboards to
support ECC on the DRAM. Very few consumer-grade boards do, and (I
believe) only a minority of business-grade boards by the Big Makers.
One tends to find ECC only in servers, or in specially-ordered
workstations.

snip

It was only fairly recently that I found a home-PC motherboard that I
liked, which had ECC support (one of the TaiChi family). It cost more to
equip the board with ECC-enabled DIMMs but I felt it was worth it in the long
run.

There are multiple AMD Ryzen motherboards that support ECC, the
problem is it is only enabled if you have a PRO CPU, not a normal
consumer one. And these are difficult to get, they are tray-type
CPUs.
And indeed, ECC RAM is slower than simple RAM, which might be an
issue especially if you use the integrated graphics of the CPU.

Mat Nieuwenhoven

 

[Martin Brown]

On 31/08/2020 19:50, Don Y wrote:

On 8/31/2020 9:29 AM, jlarkin@highlandsniptechnology.com wrote:
On Mon, 31 Aug 2020 11:46:48 -0400, Joe Gwinn <joegwinn@comcast.net
wrote:

On Mon, 31 Aug 2020 08:30:30 -0700, jlarkin@highlandsniptechnology.com
wrote:


https://en.wikipedia.org/wiki/Row_hammer


That\'s amazing. If x86 can possibly do something wrong, it does.

It is not clear that this is an x86 problem, as DRAM is used
universally, and the method depends on DRAM implementation.

Joe Gwinn

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

No.  The exploit can be applied to other processors, as well.

For example ARM cores although they are somewhat more resistant.

https://par.nsf.gov/servlets/purl/10110647

\"The second exploit revealed by Project Zero runs as an unprivileged
Linux process on the x86-64 architecture, exploiting the row hammer
effect to gain unrestricted access to all physical memory installed in
a computer.\"

We live in the Dark Ages of computing.

Makes you wonder how many of those EDA tools you use are lying to you!  :

Yes. He should go back to pencil and paper immediately.
Taped board layouts too you can\'t trust these new-fangled computers.

OTOH, REALLY makes you wonder how often the machine is NOT executing the
code (and machine state) \"as prescribed\" -- yet APPEARING to produce
good results!

These are interesting attacks against dynamic ram hardware. The
vulnerability after that depends on how it gets exploited and luck!

--
Regards,
Martin Brown

 

[Don Y]

On 9/1/2020 12:17 AM, Mat Nieuwenhoven wrote:

On Mon, 31 Aug 2020 13:46:58 -0700, Dave Platt wrote:

In article <slrnrkqli8.pap.nomail@xs9.xs4all.nl>,
Rob <nomail@example.com> wrote:

Allowing a ram data error to become a privilige escalation exploit is
a classic x86 blunder.

DRAM without ECC essentially is only suitable for toys.
All serious machines using DRAM have ECC on top of it.

By that criterion, probably 90+ percent PCs used in homes and business
offices in the United States are toys.

It was only fairly recently that I found a home-PC motherboard that I
liked, which had ECC support (one of the TaiChi family). It cost more to
equip the board with ECC-enabled DIMMs but I felt it was worth it in the long
run.

There are multiple AMD Ryzen motherboards that support ECC, the
problem is it is only enabled if you have a PRO CPU, not a normal
consumer one. And these are difficult to get, they are tray-type
CPUs.
And indeed, ECC RAM is slower than simple RAM, which might be an
issue especially if you use the integrated graphics of the CPU.

Note that ECC RAM won\'t really \"protect\" you against a \"disturb\" explooit.
It is predicated on the randomness of errors, not their *deliberate*
introduction! I.e., rowhammer can disrupt the state of multiple bits.
And, that corruption happens without the data actually being *referenced*
(i.e., the ECC isn\'t yet applied to it!)

Given that SECDED is effectively powerless at even *detecting* (let
alone CORRECTING) more than two, it is entirely possible that the RAM
will gladly report the corrupted data as \"intact\" as the syndrome has
can be equally corrupted!

And, if the OS just naively \"logs the (corrected) error\", there\'s
nothing to alert the user to the presence of this potential exploit!