Rowhammer is a hardware problem ---- defective RAM --- not a software one.
The sooner everyone starts returning defective RAM and putting pressure on the hardware manufacturers to maintain correctness, the sooner we can stop this descent into insanity.
"They can always work around it in software" is the attitude that let Rowhammer exist, and continuing to fulfill that expectation will only make things worse.
I recommend [1] as an introduction to the semiconductor physics behind the Rowhammer problem. Rowhammer is an instance of the "weird machine" problem behind many security problems, i.e. a mismatch between two abstractions: the abstraction we pretend describes the system, vs the reality of the system. In the case of Rowhammer, that is the abstraction of memory as a digital device, against the reality of storing bits with capacitors and wires, ie. analog devices. Clearly a leaky abstraction. The denser you pack those capacitors and wires, the more leaky.
I think it's important to differentiate "a mismatch between two abstractions" and "hardware bug". Because you can frame any sort of hardware (or even software!) problem like this:
"Capacitor plague of 2000 was a mismatch between two abstractions: the abstraction that capacitor actually provides datasheet-described amount of capacitance vs the reality of the system"
"Toyota unintended acceleration was a mismatch between two abstractions: the abstraction that ECU properly responds to accelerator pedal release vs the reality of the system"
Yes, digital systems are made of analog parts, but that's not a reason to accept systems behaving out of spec. For the last 50 years, the specifications for RAM have been pretty clear: as long as all datasheet requirements are obeyed, the only way to change stored data in one location should be to do a write to that location. If a memory chip does not act according to its own datasheet, it's not a "leaky abstraction", it's a hardware bug.
(Now, can this be fixed economically? I don't know, I could believe the answer is "no". However, the solution in this case is not software workarounds, but rather to make a new spec: "RH-RAM is like regular RAM but cannot tolerate certain access pattern")
Read the original Rowhammer paper where they tested various manufacturers and years --- this only started showing up around 2009, and DRAM from before that time was entirely immune to it.
> Rowhammer is a hardware problem ---- defective RAM --- not a software one.
It always amazes me how people can be so confident yet so wrong.
It's a problem of physics - there's various ways to try to mitigate it but the only way to completely avoid it would probably be to use SRAM and that is going to be extremely expensive when talking 16GB and not nearly dense enough.
> It's a problem of physics - there's various ways to try to mitigate it but the only way to completely avoid it would probably be to use SRAM and that is going to be extremely expensive when talking 16GB and not nearly dense enough.
And yet, when the bit flip problem caused by physics got so bad in DDR5 it couldn't be ignored they did fix it - by adding error correction codes. It wasn't that expensive to do so. Notice that HDD's hit the same problem as the got denser, and solved it in the same way (ie, by throwing lots of ECC at it).
I agree with the original poster. It's a hardware problem, caused by the manufacturers pushing the limits. And it's their problem to fix, which they can do. DRAM that doesn't corrupt itself isn't a big ask.
There are plenty of problems of physics in the RAM design, and it's hardware designers jobs to find the operating regime where those problems do not matter.
I mean, if you had a DRAM labeled "DDR4-3200" but it can only work at a much lower speed (say DDR4-2400), it's clearly a problem of physics - the gate capacitance is too high, the driver transistors are not strong enough. And yet my reaction would be to take that RAM back to store and get my money back, not to defend manufacturers which claim false things about their chips.
"It always amazes me how people can be so confident yet so wrong" could apply to your post too.
Yes it's a problem of physics and it's because they are trying to make DRAM too dense.
It's a problem of physics - there's various ways to try to mitigate it but the only way to completely avoid it would probably be to use SRAM
It's not some conspiracy by "Big RAM"
Look at the evidence. This didn't start showing up until around 2009-2010, and the industry managed to convince authors of widely-used memory testing tools to downplay the severity and/or not enable RH tests by default, because they didn't want the truth to be known that almost all RAM is defective. It might not be a conspiracy, but it sure is corporate greed.
Would you rather pay a little more for RAM that will work correctly under all access patterns, or RAM that is certain to produce bit errors under some conditions that can be encountered in practice? Unfortunately, with newer DDR3 and later generations, it seems you don't get a choice.
Not exactly; these constants in sudo are an enum of sorts (actually preprocessor macros). It's not just bool (and won't just be bool in many situations). It is cool to see GCC exploring automatic protection in this space; I just don't think it is relevant to what sudo did here.
Hardbool lets you use custom true and false representations with higher hamming distances. The sudo patch uses custom representations for their enum that have higher hamming distances. The only difference is that hardbool is for true/false and this patch is for AUTH_SUCCESS/AUTH_FAILURE/AUTH_ERROR etc. But that's irrelevant. It's the exact same technique.
I'm not sure how those values are derived. Yes, the Hamming distances between them should be maximized, but the current values don't seem to be optimized for that:
Sure, AUTH_SUCCESS and AUTH_FAILURE have a Hamming distance of 28, but it takes only 11 or 16 bit flips to go from AUTH_ERROR or AUTH_NONINTERACTIVE to AUTH_SUCCESS. (AUTH_ERROR can only happen from an internal error, so I believe AUTH_NONINTERACTIVE is easier to trigger.)
A quick Python search was able to find some alternatives:
0x0f7b74c5 0x810d2b99 0x63a64616 0xcab4a865 0xbe705abb
...maximizes all distances (17--19)
0x28d803a4 0x352ef6d3 0xdb61dce1 0xb3edf85c 0xe62f7508
...maximizes a distance from the first and others (21--22), disregarding other pairs (14--21)
It seems that fixing one element to be a bitwise negation of the first element is not a good search tactic in my short testing. Also as notpushkin noted, if you really want to disregard other pairs you should just make one pair with the maximal distance and derive every other code from them (say, -1 0 1 2 3 would work for this purpose).
By the way, finding a binary code with maximal Hamming distance is an open problem [1] [2].
Not really. An example out of top of my head, where this still might be useful are login nodes (used in many research clusters to allow users to enter and sumbit jobs) or shared web-hosting servers (few of those definitely still exist). There legitimate non-privileged users can run their programs and the end goal is to prevent them from getting root.
The last time I looked at the statistics the majority of the internet was still running on PHP, mostly wordpress installs. I'm willing to bet those are mostly on shared hosting with accounts separated by nothing but their linux user.
It sorta is, but isn't actually, sadly. I mean, if they were 28-bit values, they'd be binary complements, but they're actually 32-bit values, so they're really:
Doing a '!' operation in C on one of them won't yield the other value unless you also zero out the top 4 bits. Close enough, though... I still enjoy the symmetry as you did.
Anyway, I'm curious why three of the values they chose have all zeroes for the top 4 bits. I wonder if there's a security-related reason for that.
Maybe, but in practice malware that makes sudo always fail is also bad. At the same time, getting 28 precise distance from row hammer is basically impossible.
I'm also wondering why the bits are alternated in the numbers. Why can't we just set AUTH_SUCCESS to 0xffffffff and all the denied / error states to mostly-zeros?
Because you don't want to have the wrong error code even if it's a failure code.
Thus you have to figure out how to otherwise handle an enum whereby you can be reasonably assured of its value even with a flipped bit, hence the hamming distance.
I've sometimes contemplated the possibility of doing things like this to guard against memory errors causing mis-entry to particularly critical control flow paths - this is certainly an example of that. But never heard of anyone actually trying to do this until now.
A "how to write rowhammer-resistant code" writeup would definitely be useful here - even if it is definitely something people cannot do for anything, I can certainly see cases where there is a case for it.
I remember someone making a rust library for hardened bools, though with the idea of protecting against protecting against random bitflips, not targeted rowhammer attacks (though it should work about the same).
The feedback from the rust subreddit was basically protecting the bool but not the if statement is of limited use. Potentially it can even make it worse, since there is now more code being executed that might become bitflipped.
That inspired me to make a crate that periodically checksums your program code while it's running, to make sure it hasn't changed. Got it working on Windows and Linux, but then it ended up like most side projects. Maybe I should polish it up and publish it.
it's a long-known hazard in embedded and highly reliable systems, there are terms like "single-event upset" that might lead you in interesting directions
Single event upsets are well-understood and easy (although not necessarily cheap) to mitigate in hardware -- ECC for RAM, CRCs for data in flight, and voting (or lockstep if detection is sufficeint) for computation. The challenge with Rowhammer is that it involves multiple, correlated bit flips; and depending on details of your system the correlations may be disguised by various remapping layers.
I thought that Rowhammer was a thing of the past. Out of curiosity I found code to test for this and ran it on some of my hosts. My old desktop - I7-4770K/DDR3 - was susceptible. My old server - Xeon X3460/DDR3+ECC - was not. I upgraded the desktop with components based on a Ryzen 7 7700X/DDR5. It tested not susceptible. I'm not sure if that's a result of RAM designed not to be susceptible or that (I think) DDR5 RAM uses modules with on die ECC.
I was not able to test any of my Raspberry Pis because the test code used some facility available on the AMD64 architecture that is not available on the ARM64 processors. The newer Pi 4B and 5 use modules with on die ECC.
It seems to me that ECC should prevent Rowhammer susceptibility. That should prevent it on server grade H/W for anything still in service and newer consumer systems.
I have no idea if Rowhammer affects other architectures than AMD64.
RowHammer is not a thing of the past. In fact, modern DRAM chips are significantly more susceptible to RowHammer due to their increased chip density [1].
In the "countermeasures" section of the linked paper[1], it mentioned that there are some new techniques available, but repeatedly mentioned that they are not yet available in consumer systems. Maybe rowhammer will eventually be a thing of the past despite the increasing chip density.
Thanks for the link. I guess I thought wrong. But I have more questions.
> with RowHammer protection mechanisms disabled
I wonder what this means. Is it S/W mitigations or does it include H/W factors like disabling on-die ECC.
It makes sense to me that with all other things being equal that higher density would lead to more susceptibility to Rowhammer. But as always, other things are not equal. I expect that on-die ECC would reduce susceptibility to Rowhammer and AFAIK that is used for DDR4 and DDR5 RAM, but perhaps not exclusively. Or did disabling "protection mechanisms" include disabling that (if it is even possible.)
The mitigations are usually about limiting the number of times you can access without refreshing. ECC helps in detecting and correcting (obviously) but it doesn't solve the underlying issue that accessing a cell over and over can cause bit flips in neighbors. ECC can be defeated if uncorrectable errors are not fatal or if the attacker can just crash the system over and over. Being able to introduce memory errors is a fundamental and unmitigatable issue that must be resolved by making these errors impossible. This isn't a problem software can solve.
Rowhammer is not architecture specific, since it's the DRAM rather than the CPU.
The paper linked in the patch references other works showing every defence at rowhammer can be bypassed somehow (I've not followed them all) - e.g. it specifically says that ECC and the like can be bypassed.
The attacker cannot control precisely which bits will be erroneous. When much more than 2 bits become erroneous, in a small fraction of the cases no error will be detected but a wrong value will be read at the next access.
However, in the majority of the cases an error will be detected, either non-correctable, or correctable in which case the corrected value will be wrong.
Despite the fact that wrong corrections are possible, in a system with ECC that is configured correctly it should be impossible for a RowHammer attack to escape detection, unlike for a system without ECC memory.
On a computer that is not defective, memory errors happen very seldom, typically one error after many months. Even only 2 correctable errors that happen in the same day represent an event that can be explained only by either a RowHammer attack or by a memory module that has become defective.
Therefore, a well configured computer with ECC memory should alert immediately its administrator when 2 on more errors happen in the same day, even if they had been correctable errors, because this requires immediate action, either stopping a RowHammer attack or replacing the defective memory module.
It would be pretty much impossible for any RowHammer attack to attain its target without triggering 2 or more ECC errors, which will reveal the attack attempt.
Only when there is no ECC the attack can proceed undetected for a time long enough to be successful.
Shouldn't an ECC non-correctable error trigger an immediate shutdown, because bad data could be committed to disk? (I guess unsafe shutdown could cause corruption elsewhere, but that seems like a reasonable risk) If attacks are a serious threat, then it would seem any alert that doesn't trigger immediate action would be risky (i.e. the attacker just erases alerts from logs).
LPDDR4 and above are supposed to have a feature to detect too many accesses to the same few rows and initiate a refresh cycle. Implementation quality may vary.
So on RAM that needed 18,000 distance-1 accesses, they were able to mount an effective attack with 300,000 distance-2 accesses and 5000 distance-1 accesses.
That's not a particularly big assist, and doesn't sound hard to mitigate.
If TRR pushed the rows it refreshes 10% closer to triggering their own TRR, then those 300,000 accesses would have triggered multiple refreshes in the target row.
Have you ever seen any even moderately detailed specification of what the DRAM manufacturers do in this regard? I have not, and I looked. I am deeply sceptical ....
I don't believe that Rowhammer mitigations happen inside the DRAM chips themselves, I think that they are being put into the memory controller that talks to DRAM. Since DRAMs with built-in Rowhammer defences would have to spend transistors on this defence, those transistors would be 'wasted' in situations where Rowhammer is not part of the attacker model.
It makes sense to put it in the DRAM controller for many reasons. One is that the DRAM silicon process is optimized for memory but terrible for logic. Also, a DRAM bank is several chips in parallel to get the data bus width, and they would all have to duplicate the logic.
The disadvantage is that the controller and memory are made by different companies, so standards are required to agree on what access patterns are acceptable.
Agree. The extreme secrecy of DRAM manufacturers about the innards of their chips puts an additional obstacles in the way of memory controllers (MCs) implementing efficient Rowhammer defences. In particular, if the MC doesn't know which addresses are corresponding to neighbouring rows, how can an MC know with certainty that any concrete row is being attacked? (And, to the best of my knowledge, DRAM manufacturers don't give away this information.)
It might be good enough to detect a large number of accesses to any single row and then initiate a complete refresh. This wouldn't be triggered often by normal software. Most exploits have to use cache flush instructions, and with modern several-way-associative caches it would be rare for normal code to trigger it accidentally. In that case, the DRAM maker just has to specify the maximum number of accesses to any row.
My understanding from some previous papers was that many chips put in a small hash table to count accesses, and this table could be worked around.
It's easy enough to deal with if they stop cheaping out. Each row is so wide. A 10 bit counter to trigger neighbor refreshes would barely take any space.
That would cause grief to reproducible distro initiatives.
It is perfectly good enough for the error code enumeration to be statically randomized into hard coded constants. The attacker is very unlikely to flip every single bit of one valid value so that it resembles another valid value.
Even if the values were randomized at compile time, if the executable is readable to the attacker, the attacker can learn what those values are.
If the executable is not readable to the attacker, the attacker can just pull a copy of the executable from the distro package: executables are installed from widely used binary packages, not freshly compiled for every system.
> It is perfectly good enough for the error code enumeration to be statically randomized into hard coded constants.
A comment points out that they aren't randomized:
> The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.
I don't understand, isn't this pointless? I could just change some other data structure or variable, hell, I'll just change the sudo input buffer size and do a stack overflow, or a memcpy size into a heap overflow, or what stops me changing a jne (Jump if Not Equal) instruction to a jg (Jump if Greater) and bypassing the if's?
I'd argue its worse than pointless, at best it does nothing and at worse it seems to make the code harder to understand and audit, which could result in more future vulnerabilities.
The associated paper abstract claims to have broken sudo by rowhammering register values. It stands to reason that these mitigations thwart the found attacks - the commit message points to the paper as the reason for these mitigations, after all.
I think the point is that if your known attack I'd "target was shot in the right hand" making them wear a protective glove on their right hand isn't a good defense. You would want two protective gloves, a helmet and bulletproof vest.
Once you assign the values in the C enum, a switch statement is "opaque".
Just inefficient; a jump table optimization is impossible on the values. Speed is sacrificed for security. A jump table itself could be row-hammered to jump where the attacker wants!
Given that the most common use of sudo is to give yourself root to run a command, and malware looking to elevate root can just rig up ~/.bashrc, what use is this patch? What use cases does it apply to and how common are they?
Sudo has much more fine-grained abilities for more surgical use-cases, like giving users the ability to only execute certain commands as a certain user, with detailed logging and auditing. It has a pretty involved config file (the pdf docu for it is 80 pages long), a plugin system, a seperate log format and log server, etc
I also believe those use-cases aren't that common anymore since multi-user systems fell out of favor. There is an argument that most of us could use a vastly simpler tool instead to reduce the attack surface. But that tool wouldn't be sudo, because sudo is built around supporting all these use cases.
The 'exploit' runs under the sysadmin's user. It gets there when the sysadmin inadvertently installs something malicious under their own user, or something they're running is exploited for example.
Interesting it’s the exact opposite of Gray code’s goal, I suppose this has been studied, with fixed size words maximal distance problems are tractable.
This got me thinking - why we live with rowhammer and how do you take it seriously.
This is such a crazy hack to get some protection around key variables - by requiring 32-bit manipulation.
Why isn’t this just “done” on the phy layer, or somehow detected automatically in-flight? Does the compiler protect against it? At what performance penalty?
It’s really much nicer just not thinking too much about it and going on believing our bits.
Couldn't compilers be configured to use such values for for any enum type? And maybe even auto-insert the appropriate check in the final unchecked else anywhere that enum type is otherwise exhaustively checked?
The problem with C and C++ is that enum values are explicitly incrementing, even when the user does not specify a literal value for each one. So if anything depends on a specific value (e.g., disk or network formats), this will break it. I think Rust enum values are similar, but I'm not a language expert.
Rust enums are incrementing too so that they can generate machine code with dense jump tables. If you also want the discriminant value for something, you opt into that with e.g. #[repr(u8)] and you can even override the values. Note that unlike in many other languages, casting from a number to the enum is a falliable operation because not all values are valid.
Making something like this into a panic is not a good fit for Rust as-is. Because enums are proven to have only correct values, not only is code written to assume pattern matches cannot panic, but compilers are free to optimize around only having valid values as well. That goes not only for the enum discriminant, but for any associated values being properly initialized values of their respective types.
In a sense, Rust lets you write code as if invalid values never happen, so there's less to check for in your code. It's understandable from the perspective of the abstraction needed for computer code to be "correct" and not just temporarily getting away with Undefined Behavior. There are simpler ways to violate it than just rowhammer, write straight to process memory for example, which can also violate invariants that compilers assumed while optimizing.
If you wanted to compile Rust (or anything else) with a hardening mode that does check what should be redundant values, it would be a lot slower and code that never panicked before would now panic, but it would probably be a worthwhile tradeoff for some programs to opt into. After all, if you built for CHERI or arm64e and got a machine exception from an unauthenticated pointer, you'd be thrilled you mitigated a vulnerability even if it violated your higher-level language model. Defense in depth and all that.
Maybe someone feels motivated enough to write an RFC and prototype for this. It just wouldn't stop at enum values, it should mean all sorts of other things too, such as not eliding any other checks that appear redundant given assumptions like immutability. That's what makes it slow and hard to reason about.
Yes it's possible, but it's not desirable. It wouldn't be backwards compatible, and not safe for shared libraries. It's better suited for a linter-type error/warning.
It's not plausible in C, for the reasons you mention, but it might be more possible in other languages -- Rust, for example, only guarantees specific representations when instructed and doesn't allow for shared libraries without a specified representation, so it wouldn't have either issue for most application code. Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases.
> Dynamically-typed languages similarly should be able to choose enum values at runtime in many cases.
I wonder, is choosing random enum values at runtime more secure against Rowhammer than just having fixed values that were chosen randomly once and compiled in, since presumably the attacking code now has no way to know which bits it needs to flip? If so, it might even be desirable to implement this as a "secure enum" in a compiled language.
From the commit: “The values used were chosen such that it takes a large number of bit flips to change from allowed to denied. Using random values doesn't really protect against this attack.”
It would be neat to see an algorithm that generates suitable values.
The basic algorithm for the 2-enum case from the commit seems to just be `enum { A = rand(), B = ~A}`.
Although I'm not sure if it's optimal, the many case seems to be the same as the 2-case but repeated for every 2 items. I expect they double checked that the amount of bitflips is still pretty high.
Maybe a better algorithm for the many case would be something like the popcnt parallel patterns:
* 0b0101010101010101
* 0b0011001100110011
* 0b0000111100001111
* 0b0000000011111111
Since they would all have equal hamming distance between each of the entries.
Seems like an interesting compiler level protection, a decorator for enums so that they are compiled to values with maximum hamming distance between them.
Moron disclaimer: I may not be one entirely, but I frequently emulate one.
As a full-time Linux user, I haven't used sudo for years. Rather, I do 'su root'. However, I noticed several years ago (Debian) that upgrades would iterate twice, seemingly accommodating two accounts. Emulating a moron as I do, I never exerted the effort to learn why. I simply began, after 'su root', entering 'sudo su', which despite always having sudo disabled, seems to make me proper root.
I'll often use synaptic package manager when I want a cleaner, easier interface to explore packages. If I only 'su root' it won't open unless I append .... something similar to
'pkex' to the end, but if I do 'sudo su', I can run it using only 'synaptic'. Regardless, I refuse to use sudo otherwise, even when I'm emulating something sentient.
Be afraid. There are morons using Linux, and some are quite productive despite.
You should use 'su - root' to get a root login shell. Otherwise you will still keep your old environment, including $HOME and $USER.
(The man page recommends using --login over the single dash, but it also says they are equivalent. Maybe I'm too much of a moron to understand the difference, but the single dash is less typing)
This software mitigation technique for Rowhammer could also be useful for improving the reliability of programs running on microcontrollers in high radiation environments, e.g. satellite in Earth orbit.
By maximising the Hamming distance between binary values used in enumerations (enum variables) and boolean variables, one could detect if the code has entered an invalid execution path and then trigger a watchdog reset, e.g. an else statement or a switch statement with a fall through case that would not normally be reachable.
Does anyone have any opinions on doas vs sudo? I've heard doas recommended as being more minimalistic, and various advantages that brings. What are the pros and cons between the two?
My opinion is to have neither. Requiring users to switch to an account that has different privileges is evidence of poor design of the operating system. Having a root user who has full privileges over the entire system is also poor design as it is the opposite of the principle of least privilege. If a user has the privilege to do something they should be able to do it with their normal account.
I'm happy that my mistakenly typed rm -rf / fail when I use my non root user (normal account) even though I also have root for when I do want to mess things up.
When do these values get into memory, shouldn't they be in registers generally? Maybe it's when the program loaded to memory to execute, but is that part rowhammerable?
I wonder how this might work with bit-dense systems (e.g. databases like PostgreSQL) where every bit has meaning and it's wildly impractical to reassign bitpatterns like this.
I've seen bitflips on overclocked systems. Some ram is overclocked out-of-the-box; try disabling BIOS features like "XMP" (Intel Extreme Memory Profiles). Always use MemTest86 or similar to make sure your hardware is good when building a new system or changing BIOS settings.
For example 7zip decompression CRC failures that resolve on a second try. It would be longer to explain how, but I tracked it multiple times to a single bit flip in the decompressed output.
Thanks, that's pretty interesting. I'd actually be really interested if you would care to explain how, I think others would find it interesting also. I'm not even sure how I would approach trying to do that.
Typically decompressing software deletes the output file if there is a CRC error.
But I use 7zip as a library, so if I get a CRC error I still have the output. Which in my case is JSON files. By careful diffing and going over them I could identify single bit flips like '{"base": 10}' being decompressed to '{"bbse": 10}'. I made this example up, letter 'a' becoming 'b' might be a multi-bit flip, but you get the idea.
Popular compressors like 7zip are some of the best tested software on the planet, because corruption is immediately detected.
And we know hardware bugs are real, that's the whole point of rowhammer.
You might want to look at Facebook research:
> “Silent data corruptions are not limited to rare one in a million occurrences within a large-scale infrastructure. These errors are systemic and are not as well understood as the other failure modes like Machine Check Exceptions.” A large part of the responsibility should be shared by device makers, Facebook says.
The initial research into the row hammer effect, published in June 2014, described the nature of disturbance errors and indicated the potential for constructing an attack, but did not provide any examples of a working security exploit. [1]
[1] (June 24, 2014). "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors"
By my recollection there was a discussion of rowhammer and making it work on a (original) Freenode channel circa 2010 (or earlier) in response to a related thread on a reddit security hacking subreddit.
ie: it was being discussed in public channels some four years prior to a paper cited as "initial research".
Addendum: Mind you, lots of things get kicked about and implemented before actual papers appear on them for the first time in public.
Well, that quote from Wikipedia says the published paper didn't include a working exploit. That might be true even if a working exploit was available after the paper was written and submitted but before it was published. (I don't know if this is the case here, but this sort of thing is common in scientific publishing.)
Mind you, lots of things get kicked about and implemented before actual papers appear on them for the first time in public.
I was thinking of many examples I know where a technique is developed and used in industry (mineral exploration | remote imaging | secret spook stuff) and much later (five years or more) gets a first mention in acedemia .. where they may or may not get a robust working version happening .. just a rickety proof of concept.
The possibility of flipping bits in DRAM in a Rowhammer like fashion, was known in the DRAM industry since at least the 1990s (sorry, no reference handy), and Rowhammer-like access was used in DRAM quality testing.
As silicon density increased, the issue became more urgent.
That matches my recollection- I started in broad STEM at university in the 1980s and as chip sizes were pushed smaller and denser there was always thought given to signal bleed | harmonics from too many lines too close together.
I suspect "observed in fabrication lab | not disclosed" dates back some years before the paper .. once observed there's always a path to exploitation - but why would anyone broadcast that?
By the time it was chit chat on IRC the general feeling was that some TLA has a working exploit. (obviously unpublished).
Rust makes a particular class of bugs harder to write. That’s it. It doesn’t magically eliminate all bugs. “Susceptible to rowhammer” is not in the class of bugs that Rust helps with.
No experienced Rust programmer actually believes it magically prevents all bugs or magically makes security-sensitive code immune to side channel attacks, so I don’t think anyone is being lulled into a false sense of security, no.
What about the Non-experienced Rust programmer? A lot of open source code are written by inexperienced people who understand the nuances of computer science primarily through hype. I think those are the kinds of people OP was asking about.
An inexperienced programmer is much more likely to make security-critical mistakes writing C or C++ than Rust anyway, even if they’re aware of the concept of undefined behavior, so I think Rust still has an advantage in this case.
You should avoid using security-critical tools written by people who don’t understand security, regardless of language.
Yet the vocal majority of Rust users present themselves as being inexperienced programmers. I expect it is not just an act – that the vocal majority truly are inexperienced, and I expect the segment of users who are novices is much larger than you suggest.
The fact of the matter is that the novices have always been drawn to the 'hot new technology' and it is unlikely that Rust, being today's 'hot new technology', is the exception. Indeed, Python and Javascript had time in the sun when they were considered hot, and novices were attracted in that direction at that time, but time continues to march forward.
They do. To be fair, vocal majorities generally are inexperienced, even outside of Rust communities. Of course they are. What would someone with experience gain from such vocal exchange?
The vocal majority of Rust users are especially vocal in tech circles right now, though, because of it being the "hot new technology" and thus most attractive to inexperienced programmers. This does make their inexperience stand out in an especially prominent way. All "hot new technologies" have gone through this pain period.
That doesn't mean that there aren't experienced Rust users, but experienced users have no reason to talk about it. Their experience has already collected everything that could be gained through vocalization. Talking about it becomes boring at that point.
Some novices do in fact write Rust, just like how many of them gain experience in C and C++ during undergrad. With any luck, universities will adopt something safer like Rust…
Do not want.
Rowhammer is a hardware problem ---- defective RAM --- not a software one.
The sooner everyone starts returning defective RAM and putting pressure on the hardware manufacturers to maintain correctness, the sooner we can stop this descent into insanity.
"They can always work around it in software" is the attitude that let Rowhammer exist, and continuing to fulfill that expectation will only make things worse.