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/fsp2...
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/fsp2...
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
On 07.12.18 22:46, Taiidan@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
So, at first we have a non-specific ad-hominem attack:
On Fri, Dec 7, 2018 at 1:53 PM Taiidan@gmx.com Taiidan@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-hypervis...
"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@gmx.com Taiidan@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/fsp2...
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@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@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@gmx.com Taiidan@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-hypervis...
"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.
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@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@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@gmx.com Taiidan@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-hypervis...
"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 -
emanuele -
Nico Huber -
ron minnich -
Taiidan＠gmx.com