Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DRAM has a design flaw from 1966. I bypassed it [video]

youtube.com

Post reply on HN
Print view View original

81–90 of 174 posts

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#81

Post by vitus »

em-bee wrote: post #75
alex_duf wrote: post #57

Earlier quoted context omitted.

it's explained in the video, and there's no way I'll be explaining it better than her

you could however link to the timestamp where that particular explanation starts. i am afraid i don't have time to watch a one hour video just to satisfy my curiosity.

This is approximately the section in the video titled "Memory controllers hate you" (https://www.youtube.com/watch?v=KKbgulTp3FE&t=1399s), combined with the following section.

The actual explanation starts a couple minutes later, around https://youtu.be/KKbgulTp3FE?t=1553. The short explanation is performance (essentially load balancing against multiple RAM banks for large sequential RAM accesses), combined with a security-via-obscurity layer of defense against rowhammer.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#82

Post by vitus »

100ms wrote: post #53
why_only_15 wrote: post #39

Earlier quoted context omitted.

This is a quite old technique. The idea, as I understood it, was that lots of data at Google was stored in triplicate for reliability purposes. Instead of fetching one, you fetched all three and then took the one that arrived first. Then you sent UDP packets cancelling the other two. For something like search where you're issuing hundreds of requests that have to resolve in a few hundred milliseconds, this substantia…

Aha that makes more sense, I thought it was specifically to do with job scheduling from the description. You can do something similar at home as a poor man's CDN by racing requests to regionally replicated S3 buckets. Also magic eyeballs (ipv4/v6 race done in browsers and I think also for Quic/HTTP selection) works pretty much the same way

> magic eyeballs

https://en.wikipedia.org/wiki/Happy_Eyeballs is the usual name. It's not quite identical, since you often want to give your preferred transport a nominal headstart so it usually succeeds. But yes, there are some similarities -- you race during connection setup so that you don't have to wait for a connection timeout (on the order of seconds) if the preferred mechanism doesn't work for some reason.

The main term I've seen for this particular approach is "request hedging" (https://grpc.io/docs/guides/request-hedging/, which links to the paper by Dean and Barroso).

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#83

Post by vintermann »

em-bee wrote: post #76
fc417fc802 wrote: post #51

Earlier quoted context omitted.

> I cant read a blog post in the background You can consume technical content in the background?

if your foreground work doesn't occupy your brain, why not?

Because I prefer not to think about the hair I'm removing from my shower drain?

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#84

Post by derbOac »

svrtknst wrote: post #50
throwaway81523 wrote: post #32

Earlier quoted context omitted.

This is a 54 minute video. I watched about 3 minutes and it seemed like some potentially interesting info wrapped in useless visuals. I thought about downloading and reading the transcript (that's faster than watching videos), but it seems to me that it's another video that would be much better as a blog post. Could someone summarize in a sentence or two? Yes we know about the refresh interval. What is the bypass? Up…

Unnecessarily negative imo. I like the video because I cant read a blog post in the background while doing other stuff, and I like Gadget Hackwrench narrating semi-obscure CS topics lol

FWIW, I like her videos but I usually prefer essays or blog posts in general as they're easier to scan and process at my own rate. It's not about this particular video, it's about videos in general.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#85

Post by UltraSane »

saidnooneever wrote: post #49
UltraSane wrote: post #10

Earlier quoted context omitted.

The clever part is figuring out what RAM is controlled by which controllers.

everyone says this but no one says why it was clever. i find her videos have cool results but i cant have patience for them usually because its recycled old stuff (can be cool but its not ground breaking). there is a ton of info you can pull from: smbios, acpi, msrs, cpuid etc. etc. about cpu/ram topology and connecticity, latencies etc etc. isnt the info on what controllers/ram relationships exists somewhere in ther…

The exact mapping between RAM addresses and memory controllers is intentionally abstracted by the memory subsystem with many abstraction layers between you and the physical RAM locations. Because documentation is sometimes incomplete or proprietary, security researchers often have to write software that probes memory and times the access speeds to reverse-engineer the exact interleaving functions of a specific CPU. in the video she says that ARM CPUs have the least data about this and she had to rely entirely on statistical methods.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#86

Post by namibj »

guenthert wrote: post #45
boznz wrote: post #8

Should say DRAM, SRAM does not have this.

Indeed. And only for certain DRAM refresh strategies. I mean, it's at least conceivable that a memory management system responsible for the refresh notices that a given memory location is requested by the cache and then fills the cache during the refresh (which afaiu reads the memory) or -- simpler to implement perhaps -- delays the refresh by a μs allowing the cache-fill to race ahead. (seems that in the earlier sub…

None of the DDR2 and onwards memories have anywhere near enough bandwidth to meet refresh frequency on each bit by you even just reading it in a loop.

The refresh that we do is run in parallel on the memory arrays inside the RAM chips completely bypassing any of the related IO machinery.

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#87

Post by 100ms »

vitus wrote: post #82
100ms wrote: post #53

Earlier quoted context omitted.

Aha that makes more sense, I thought it was specifically to do with job scheduling from the description. You can do something similar at home as a poor man's CDN by racing requests to regionally replicated S3 buckets. Also magic eyeballs (ipv4/v6 race done in browsers and I think also for Quic/HTTP selection) works pretty much the same way

> magic eyeballs https://en.wikipedia.org/wiki/Happy_Eyeballs is the usual name. It's not quite identical, since you often want to give your preferred transport a nominal headstart so it usually succeeds. But yes, there are some similarities -- you race during connection setup so that you don't have to wait for a connection timeout (on the order of seconds) if the preferred mechanism doesn't work for some reason. The…

Happy eyeballs, that makes a lot more sense thanks. Someone's "magic eyeballs" here apparently isn't reading his own writing :)

Re: DRAM has a design flaw from 1966. I bypassed it [video]

#89

Post by ahoka »

bronlund wrote: post #79
ahoka wrote: post #52

Earlier quoted context omitted.

Companies are standing in line to double their RAM usage right now, right.

For an HFT firm, RAM cost is a non-issue. Even the tiniest improvement in latency can result in millions of dollars of extra profit. They can octuple their RAM usage and still make a killing. I bet Citadel already has reached out to Laurie :)

[flagged]
Post reply on HN