For those interested, the key takeaway from this IMO is that by issuing many sequential reads, the memory controller will hold a target row open for an extended amount of time to service the consecutive accesses.
This is in contrast to the original rowhammer attack, which issues accesses such that target rows are repeatedly opened and closed to trigger bitflips in neighboring rows.
By stretching out the row open time to 30ms (!), the authors claim they are able to reliably trigger bitflips with a single row opening in 13% of tested rows at 50°C[1]. Some rows in certain chips can be flipped with access times of under 10ms[2].
At more realistic row open times of 7.8 - 70us, there seems to be a 1/x relationship between row open time and number of activations required, they cumulative amount of time the row needs to be held open for to trigger a flip seems to remain fairly constant (around 50ms total from my very approximate estimations). Note that the attack needs to be executed in under 64 ms total, otherwise the automatic DRAM refresh will reset any progress made.
The authors demonstrate this attack with a userspace program that maps a 1 GB hugepage to be able to directly manipulate the lower 30 physical address bits[3], although they don't seem to provide the row open times they end up being able to achieve in practice.
So this is a direct DRAM spec violation: there is a spec in the DRAM datasheet known as tRAS (row address strobe: time from row open (read) to row close (write back)). Min is 33 ns, Max is 9*tREFI. tREFI (average refresh period) depends on temperature: for below 85C, it's 7.8 us. So tRAS max is 70 us. (this is from some random Micron DDR4 datasheet)
Um, so of course they can trigger problems when they violate the spec!
Were they able to find a DRAM controller that violates the spec? If so, that's a simple bug in the DRAM controller. Well I guess so, the paper mentions Intel i5-10400 (Comet Lake). Do AMD processors have this issue?
I too am not seeing the gotcha here. The paper seems to be:
1. We ran a bunch of DDR4 outside spec directly with an FPGA, and the ram failed to nobody's surprise, and we characterized it.
2. We found a way to bamboozle the CPU's ram controller to achieve a similar effect.
I've written SDR, DDR1/2 ram controllers in verilog, I'm very familiar with autorefresh timing. You need to refresh each row every 64ms, and if you have, say , 1024 rows, then you must issue an autorefresh at least every 62uS. In newer rams there are some allowances to optimize for PVT, but this is a fundamental requirement of DRAM spanning almost 40 years.
In ye olden days of EDO and FPM drams, before synchronous, you had to manually select each row to refresh. Nowadays you just send autorefresh command with no argument. The chip itself maintains a row counter and auto increments it for round robin refresh.
I see 2 potential snags. The first is, JEDEC says that you're sometimes allowed to defer refresh 9 periods. But you do have to refresh more later to make up for it.
The second is if Intel cut corners in their controller.
The controller should enforce a hard cutoff after the row stays open too long. The paper mentions this as a potential mitigation (but isn't this simply a hard design rule anyway?)
The paper mentions such mitigations would not work because "the row would've been open for too long before refresh anyway". This bafflingly circular logic I cannot follow.
After having read the document now I think I see the misunderstanding.
From my understanding the attack is:
1. Hold a row open for 70us
2. Ram controller may refresh a row
3. Go to 1
I saw nothing that mentioned a hard requirement of 64ms referenced in the post you replied to - they only mentioned that they kept it within 64ms to
"Prevent data-retention failures from interfering with read-disturb failures"
«Importantly, the researchers haven't demonstrated that ECCploit works against ECC in DDR4 chips, a newer type of memory chip favored by higher-end cloud services. They also haven't shown that ECCploit can penetrate hypervisors or secondary Rowhammer defenses. Nonetheless, the bypass of ECC is a major milestone»
Try adding the EasyList Cookie List[0] to your adblocker to block them all.
It's present in the uBlock Origin filter list settings under Annoyances but not enabled by default. HN readers may also find some of the other default disabled filter lists interesting such as the AdGuard URL Tracking Protection list which strips tracking parameters from URLs.
Note that using this blocker list can actually increase first party tracking if it blocks a properly configured user respecting consent management platform.
Not all consent managers are just forms. Some of them contain enforcement technology and some block lists do not differentiate between the forms and the enforcement technology, even when the consent managers make it easy to differentiate and block individual components.
For example, the manner in which Brave blocks Transcend Consent Manager can increase first party tracking due to Transcend Consent Manager being blocked in its entirety.
I'm not sure where your getting this from, a phone number is _optional_ for CSGO, adding one is said to improve your "trust factor"[0], theoretically improving your matchmaking experience.
I don't believe TF2 has any sort of phone number system that I'm aware of. If there is one, it doesn't seem to function very well given the bot invasion over the last few years.
> I don't believe TF2 has any sort of phone number system that I'm aware of. If there is one, it doesn't seem to function very well given the bot invasion over the last few years.
If I remember correctly, in TF2 competitive mode and Mann vs Machine (pve) gets locked if you don't have steam guard enabled. But you still have access to casual and community servers, which are what you will usually want to play.
CSGO used to require a phone number. It changed a bit to be "optional", but all that really means now is that they made the system more opaque.
It used to be that to get prime queue (or whatever it was called) you need to phone number, since the open queue was filled with hackers. The new systems still attempts to do the same, just without the hard boundary. You may end up in the hacker lobby, or you may not. You won't know.
One way of doing all this stuff is creating "haves" and "have nots" where those who have a higher credit score from age of account, phone number, etc, get better matchmaking (against players of a similar high score) than those who forgo those things.
I'm going off of memory mostly. I'm pretty sure all three asked me for a phone number to play ranked, but apparently it's optional at least for CS:GO. The impression I was given though was "give your phone number or you'll only ever play with hackers and smurfs" such that it was basically required.
I'm confused, have you found the try operator ("?") insufficient for your use cases? I believe it does what you are describing, ex:
fn process_file(p: Path) -> Result<String, io::Error> {
let file = File::open(p)?; //Return err if file can't be opened
let mut out = String::new();
file.read_to_string(&mut out)?; // Return err if read fails
out
}
If you want to handle the error case within the same function `try` blocks are available in nightly[0] and will eventually come to stable[1]
`?` only helps if the thing you want to do on Err is return from the whole function. You can't use it for finer-grained break / continue / exit-from-current-block (until `try` blocks are stabilized).
> I bought the camera used recently and didn’t update the exif date in the camera. I uploaded it on Wikipedia and I’m cool with it without copyright. The image is for the people. Patrickamackie2 (talk) 05:39, 28 November 2020 (UTC)patrickamackie
While I believe that it would be better for society if the court sides with Google, I personally think that APIs can be a creative work, and thus would have copyright protection under the law. However one of Google's arguments is that Oracle is trying to use copyright to acquire a patent-like right, referencing the case of Baker v. Selden[0]. Despite being from 1879(!) I found this case to be especially relevant and I'm quite interested to see how the court will consider it into their opinion.
In his arguments, Oracle's lawyer argues that declaring code is not distinguishable from implementing code and thus deserves all the same copyright protections. As a programmer I find this argument quite unconvincing, as there is clearly a technical distinction in many systems, see: .h files, dynamic linking, etc.
[0] https://web.archive.org/web/20010111052400/http://www.csse.m...
[1] https://metacpan.org/release/DCONWAY/Lingua-Romana-Perligata...