Rowhammer mitigation: RH activation probability

[emanuele]

Hello everyone,
I know some system has support for a particular feature against 
Rowhammer attack.
The "RH activation probability" settings allows to refresh a row with a 
tunable probability.

For example some AMI BIOS version include this option: 
https://forums.puri.sm/t/row-hammer/793/7

I have found a trace in coreboot code here: 
https://github.com/siro20/coreboot/blob/master/src/vendorcode/intel/fsp/fsp…

Anyone know if this option is currently available on coreboot?
Thank you all!

On 12/07/2018 03:28 PM, emanuele wrote:
  Hello everyone,
 I know some system has support for a particular feature against
 Rowhammer attack.
 The "RH activation probability" settings allows to refresh a row with a
 tunable probability.
 
 For example some AMI BIOS version include this option:
 https://forums.puri.sm/t/row-hammer/793/7
I would like to note that company has provided poor security advice on a
variety of occasions - if you want good advice I would ask people here
or on the gentoo ML since both seem to have a large amount of
experts...I also provide free advice for expert level technical
questions so you can email me as well.

  
 I have found a trace in coreboot code here:

https://github.com/siro20/coreboot/blob/master/src/vendorcode/intel/fsp/fsp…
Do you mean this and its related options?

/** Offset 0x04AB - Enable RH Prevention
  Enables/Disable RH Prevention
  $EN_DIS
**/

/** Offset 0x04F7 - Row Hammer Solution
  Type of method used to prevent Row Hammer. Default is Hardware RHP
  0:Hardware RHP, 1:2x Refresh
**/

It appears the same as in the screenshot since AMI BIOS like coreboot
uses Intel FSP for hardware init (all new intel hardware uses fsp blobs
for hw init)

AFAIK there aren't any non development boards that use cannonlake and
since the hardware initiation is blobbed it would be hard to find out
how it works or test it to see if really does what it says unless we can
get someone from intel to comment here.

In my experience proprietary firmware frequently has options that aren't
actually implemented or don't do what they say they do.

  
 Anyone know if this option is currently available on coreboot?

rowhammer is almost entirely a laptop problem or for that matter
anything that uses SODIMM's due to their high density.

The ivy/sandybridge hw init code like for x220/t420/w520 laptops etc had
its ram refresh rates doubled a few years back to fix the rowhammer
problem similarly to the second option in the bios screenshot you linked.

No idea about any other coreboot laptops and I am interested to know
about the AGESA series like the g505s (which have open cpu/ram hw init)

The expensive laptops with ECC are not really worth it since ECC doesn't
fix the issue...although one might be alerted from errors in the log and
could set the system to halt if any pop up preventing whatever the evil
program wants to do.

  Thank you all!
Yea hello and welcome :D

[Nico Huber]

On 07.12.18 22:46, Taiidan(a)gmx.com wrote:
  rowhammer is almost entirely a laptop problem or for
that matter
 anything that uses SODIMM's due to their high density.
That doesn't seem right. Can you give any examples of chips commonly
used on SO-DIMMs that can't be found on DIMMs? I had the feeling you
find the same chips on both. SO-DIMMs often host 16 chips. If you'd
want the same capacity on a DIMM with less chip density, you'd need
32 chips (or physically bigger chips). Never seen that (though didn't
look for it either).

Nico

[ron minnich]

So, at first we have a non-specific ad-hominem attack:

On Fri, Dec 7, 2018 at 1:53 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
  I would like to note that company has provided poor
security advice on a
 variety of occasions
followed by poor security advice:

  rowhammer is almost entirely a laptop problem or for
that matter
 anything that uses SODIMM's due to their high density.
which is immediately disproven with a 3 term search on google:
https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervi…

"The Google Project Zero team led the way in discovering practical
Rowhammer attacks against client platforms. Google production machines
use double refresh rate to reduce errors, and ECC RAM that detects and
corrects Rowhammer-induced errors."

so, please all, no ad-hominem attacks, and if you're going to make a
technical claim, please be ready to provide justification.

thanks

ron

On Fri, Dec 7, 2018 at 1:53 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
>
> On 12/07/2018 03:28 PM, emanuele wrote:
> > Hello everyone,
> > I know some system has support for a particular feature against
> > Rowhammer attack.
> > The "RH activation probability" settings allows to refresh a row with
a
> > tunable probability.
> >
> > For example some AMI BIOS version include this option:
> > https://forums.puri.sm/t/row-hammer/793/7
>
> I would like to note that company has provided poor security advice on a
> variety of occasions - if you want good advice I would ask people here
> or on the gentoo ML since both seem to have a large amount of
> experts...I also provide free advice for expert level technical
> questions so you can email me as well.
>
> >
> > I have found a trace in coreboot code here:
> >
https://github.com/siro20/coreboot/blob/master/src/vendorcode/intel/fsp/fsp…
>
> Do you mean this and its related options?
>
> /** Offset 0x04AB - Enable RH Prevention
>   Enables/Disable RH Prevention
>   $EN_DIS
> **/
>
> /** Offset 0x04F7 - Row Hammer Solution
>   Type of method used to prevent Row Hammer. Default is Hardware RHP
>   0:Hardware RHP, 1:2x Refresh
> **/
>
> It appears the same as in the screenshot since AMI BIOS like coreboot
> uses Intel FSP for hardware init (all new intel hardware uses fsp blobs
> for hw init)
>
> AFAIK there aren't any non development boards that use cannonlake and
> since the hardware initiation is blobbed it would be hard to find out
> how it works or test it to see if really does what it says unless we can
> get someone from intel to comment here.
>
> In my experience proprietary firmware frequently has options that aren't
> actually implemented or don't do what they say they do.
>
> >
> > Anyone know if this option is currently available on coreboot?
>
>
  rowhammer is almost entirely a laptop problem or for
that matter
 anything that uses SODIMM's due to their high density.
>
> The ivy/sandybridge hw init code like for x220/t420/w520 laptops etc had
> its ram refresh rates doubled a few years back to fix the rowhammer
> problem similarly to the second option in the bios screenshot you linked.
>
> No idea about any other coreboot laptops and I am interested to know
> about the AGESA series like the g505s (which have open cpu/ram hw init)
>
> The expensive laptops with ECC are not really worth it since ECC doesn't
> fix the issue...although one might be alerted from errors in the log and
> could set the system to halt if any pop up preventing whatever the evil
> program wants to do.
>
> > Thank you all!
>
> Yea hello and welcome :D
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

Upon doing more research I am noting in regards to my previous post
about vendors who claimed to solve the problem by doubling the RAM
refresh rate in their firmware that according to [1] it only postpones
the problem rather than eliminating it.

[1]
https://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug…

On 12/14/2018 03:20 AM, Nico Huber wrote:> On 07.12.18 22:46,
Taiidan(a)gmx.com wrote:
  rowhammer is
almost entirely a laptop problem or for that matter
 anything that uses SODIMM's due to their high density.
 That doesn't seem right. Can you give any examples of chips commonly
 used on SO-DIMMs that can't be found on DIMMs?
Ahhh good point commodity parts.

  I had the feeling you find the same chips on both.
SO-DIMMs often host
16 chips. If you'd
  want the same capacity on a DIMM with less chip
density, you'd need
 32 chips (or physically bigger chips). Never seen that (though didn't
 look for it either).
I had read it somewhere awhile back when the problem first appeared
stating that it didn't appear as much in desktops and servers due to
lower density RAM which made sense to me considering the size difference
I also tested my various home computers and only my laptops had a
problem not the desktops/servers (all have ecc but it didn't show any
errors) so I figured that it was an accurate statement. This shows the
value of going back to quickly research something before providing the
statement (and having others who aren't me to review!)


On 12/14/2018 12:21 PM, ron minnich wrote:

  So, at first we have a non-specific ad-hominem attack:
I want people to get the best advice possible (hence my list of
alternative sources) and while I can cite examples I am prohibited from
potentially starting arguments about them so I do not want to.

To me providing good advice is important since someone reading it could
be facing a life or death situation such as a journalist in a hostile
country and why I always apologize and note a correction if I give wrong
advice. I am also a better sysadmin than I am a programmer so I
concentrate on my strong points.

  
 On Fri, Dec 7, 2018 at 1:53 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote:
  I would like to note that company has provided
poor security advice on a
 variety of occasions
 
 followed by poor security advice:
 
  rowhammer is almost entirely a laptop problem or
for that matter
 anything that uses SODIMM's due to their high density.
 
 which is immediately disproven with a 3 term search on google:

https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervi…
 
 "The Google Project Zero team led the way in discovering practical
 Rowhammer attacks against client platforms. Google production machines
 use double refresh rate to reduce errors, and ECC RAM that detects and
 corrects Rowhammer-induced errors."
 
 so, please all, no ad-hominem attacks, and if you're going to make a
 technical claim, please be ready to provide justification.
I had read it in a whitepaper somewhere and I am attempting to find out
where.

That is a good idea to have a citation on hand for claims like this and
I will do so from now on as if I were editing the wiki.

  
 thanks
 
 ron
If a post of mine is not acceptable then I encourage you or others to
exorcise your right to deny it as sometimes I do not realize what is and
what isn't considered okay.

[Carl-Daniel Hailfinger]

Actually, the latest Rowhammer attack is harder to exploit on laptops
due to the power saving features for row activation. Servers use a
different row activation strategy which has better performance, but also
enables one-location hammering.
See Gruss, Lipp, Schwarz, Genkin et al.:
Another Flip in the Wall of Rowhammer Defenses
2018 IEEE Symposium on Security and Privacy

Regards,
Carl-Daniel

On 14.12.2018 23:36, Taiidan(a)gmx.com wrote:
  Upon doing more research I am noting in regards to my
previous post
 about vendors who claimed to solve the problem by doubling the RAM
 refresh rate in their firmware that according to [1] it only postpones
 the problem rather than eliminating it.

 [1]
 https://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug…

 On 12/14/2018 03:20 AM, Nico Huber wrote:> On 07.12.18 22:46,
 Taiidan(a)gmx.com wrote:
  rowhammer
is almost entirely a laptop problem or for that matter
 anything that uses SODIMM's due to their high density.
 That doesn't seem
right. Can you give any examples of chips commonly
 used on SO-DIMMs that can't be found on DIMMs?
 Ahhh good point commodity
parts.

  I had the feeling you find the same chips on
both. SO-DIMMs often host
 16 chips. If you'd
  want the same capacity on a DIMM with less chip
density, you'd need
 32 chips (or physically bigger chips). Never seen that (though didn't
 look for it either).
 I had read it somewhere awhile back when the problem first
appeared
 stating that it didn't appear as much in desktops and servers due to
 lower density RAM which made sense to me considering the size difference
 I also tested my various home computers and only my laptops had a
 problem not the desktops/servers (all have ecc but it didn't show any
 errors) so I figured that it was an accurate statement. This shows the
 value of going back to quickly research something before providing the
 statement (and having others who aren't me to review!)


 On 12/14/2018 12:21 PM, ron minnich wrote:

  So, at first we have a non-specific ad-hominem
attack:
 I want people to get the best advice possible (hence my list of
 alternative sources) and while I can cite examples I am prohibited from
 potentially starting arguments about them so I do not want to.

 To me providing good advice is important since someone reading it could
 be facing a life or death situation such as a journalist in a hostile
 country and why I always apologize and note a correction if I give wrong
 advice. I am also a better sysadmin than I am a programmer so I
 concentrate on my strong points.

  On Fri, Dec 7, 2018 at 1:53 PM Taiidan(a)gmx.com
<Taiidan(a)gmx.com> wrote:
  I would like to note that company has provided
poor security advice on a
 variety of occasions
 followed by poor security advice:

  rowhammer is almost entirely a laptop problem or
for that matter
 anything that uses SODIMM's due to their high density.
 which is immediately
disproven with a 3 term search on google:

https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervi…

 "The Google Project Zero team led the way in discovering practical
 Rowhammer attacks against client platforms. Google production machines
 use double refresh rate to reduce errors, and ECC RAM that detects and
 corrects Rowhammer-induced errors."

 so, please all, no ad-hominem attacks, and if you're going to make a
 technical claim, please be ready to provide justification.
 I had read it in a
whitepaper somewhere and I am attempting to find out
 where.

 That is a good idea to have a citation on hand for claims like this and
 I will do so from now on as if I were editing the wiki.

  thanks

 ron
 If a post of mine is not acceptable then I encourage you or others to
 exorcise your right to deny it as sometimes I do not realize what is and
 what isn't considered okay.