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