How much/what hardware does the rowhammer DRAM bug affects?
This is old, but haven't seen it here. https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug... --- Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory. --- There is POC. Variant via javascript: https://github.com/IAIK/rowhammerjs How much/what hardware does this bug affect?
I don't actually know the answer to this, but in a summary article on the JS exploit they opened by saying part of its beauty was how many wonderfully peculiar preconditions were required before it became possible. Browser model, JS engine, hardware acceleration options, possibly firmwares, and DRAM model/generation/clockspeed. No reason to be complacent, but the gist was "you probably don't need to worry about rowhammer-JS". Rowhammer itself, OTOH, who knows? :) On 16/09/15 10:01, Georgi Guninski wrote:
This is old, but haven't seen it here.
https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug...
--- Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory. ---
There is POC.
Variant via javascript:
https://github.com/IAIK/rowhammerjs
How much/what hardware does this bug affect?
-- Scientific Director, IndieBio EU Programme Now running in Cork, Ireland May->July Learn more at indie.bio and follow along! Twitter: @onetruecathal Phone: +353876363185 miniLock: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM peerio.com: cathalgarvey
On Wed, Sep 16, 2015 at 10:12:36AM +0100, Cathal Garvey wrote:
I don't actually know the answer to this, but in a summary article on the JS exploit they opened by saying part of its beauty was how many wonderfully peculiar preconditions were required before it became possible. Browser model, JS engine, hardware acceleration options, possibly firmwares, and DRAM model/generation/clockspeed.
No reason to be complacent, but the gist was "you probably don't need to worry about rowhammer-JS".
OK, javascript vector aside (it is at least theoretical threat, but ATM don't see how a page can exploit it only with this attack without additional bug).
Rowhammer itself, OTOH, who knows? :)
This appears real threat according to claims and the POC.
On 16/09/15 10:01, Georgi Guninski wrote:
This is old, but haven't seen it here.
https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug...
--- Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory. ---
There is POC.
Variant via javascript:
https://github.com/IAIK/rowhammerjs
How much/what hardware does this bug affect?
On Wed, 16 Sep 2015 10:12:36 +0100 Cathal Garvey <cathalgarvey@cathalgarvey.me> wrote:
possible. Browser model, JS engine, hardware acceleration options, possibly firmwares, and DRAM model/generation/clockspeed. No reason to be complacent, but the gist was "you probably don't need to worry about rowhammer-JS".
It makes one wonder how well it works in the context of node.js, which seems to be the darling of developers the world over these days. -- The Doctor [412/724/301/703/415] [ZS] PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "You've seen one elemental core, you've seen 'em all."
On Fri, Sep 18, 2015 at 10:11:00AM -0700, The Doctor wrote:
On Wed, 16 Sep 2015 10:12:36 +0100 Cathal Garvey <cathalgarvey@cathalgarvey.me> wrote:
possible. Browser model, JS engine, hardware acceleration options, possibly firmwares, and DRAM model/generation/clockspeed. No reason to be complacent, but the gist was "you probably don't need to worry about rowhammer-JS".
It makes one wonder how well it works in the context of node.js, which seems to be the darling of developers the world over these days.
http://arxiv.org/abs/1507.06955 Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript p.2 We compared our implementations of the Rowhammer attack on the three different machines shown in Table I. (gives explicit models).
From: Georgi Guninski <guninski@guninski.com> This is old, but haven't seen it here. https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug...
Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory. There is POC. Variant via javascript: https://github.com/IAIK/rowhammerjs How much/what hardware does this bug affect? This brings me back to my stint at Intel, 1980-82, as a new Product Engineer for the 2186, an 8kx8 pseudostatic (self-refreshing dynamic) RAM. (One of the first DRAMs to use redundancy to increase yield.) I may have been the first engineer in the world to see, through a microscope focused on a DRAM chip, a very quick series of flashes, evidence of the programming (blowing) silicon fuses on the chip, to program the row- and column-redundancy information. Product engineers were, and presumably still are, responsible for writing test programs to run chips through their paces, in Intel's case using a Teradyne computer. http://www.teradyne.com/products/semiconductor-test/magnum-v I don't think the concept of this kind of weakness is new: Even in 1980, DRAMs were tested for such repeated accesses, to ensure that such errors would not occur. This was particularly true for a process called "device characterization", in which chips were attacked in all manner of electronically-abusive ways, to uncover these weaknesses, and fix the circuit design should such flaws be uncovered. One way these techniques could be thwarted is to return to the use of parity-bits (8+1 parity) in memory access, in DRAM module and computer design, to whatever extent they are no longer used. Any (successful) attempt to modify bits in a DRAM would quickly end up causing a parity error, which would at least show which manufacturer's DRAM chips are susceptible to this kind of attack. A person who was forced to use a no-parity computer could, at least, limit his purchases of such modules to those populated with DRAMs not susceptible to the problem. Jim Bell
On Wed, Sep 16, 2015 at 4:03 PM, jim bell <jdb10987@yahoo.com> wrote:
From: Georgi Guninski <guninski@guninski.com> This is old, but haven't seen it here. https://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug...
Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory. There is POC. Variant via javascript: https://github.com/IAIK/rowhammerjs How much/what hardware does this bug affect?
This brings me back to my stint at Intel, 1980-82, as a new Product Engineer for the 2186, an 8kx8 pseudostatic (self-refreshing dynamic) RAM. (One of the first DRAMs to use redundancy to increase yield.) I may have been the first engineer in the world to see, through a microscope focused on a DRAM chip, a very quick series of flashes, evidence of the programming (blowing) silicon fuses on the chip, to program the row- and column-redundancy information.
Product engineers were, and presumably still are, responsible for writing test programs to run chips through their paces, in Intel's case using a Teradyne computer. http://www.teradyne.com/products/semiconductor-test/magnum-v
I don't think the concept of this kind of weakness is new: Even in 1980, DRAMs were tested for such repeated accesses, to ensure that such errors would not occur. This was particularly true for a process called "device characterization", in which chips were attacked in all manner of electronically-abusive ways, to uncover these weaknesses, and fix the circuit design should such flaws be uncovered. One way these techniques could be thwarted is to return to the use of parity-bits (8+1 parity) in memory access, in DRAM module and computer design, to whatever extent they are no longer used. Any (successful) attempt to modify bits in a DRAM would quickly end up causing a parity error, which would at least show which manufacturer's DRAM chips are susceptible to this kind of attack. A person who was forced to use a no-parity computer could, at least, limit his purchases of such modules to those populated with DRAMs not susceptible to the problem. Jim Bell
Some paper has said systems using ECC RAM are resistant / immune to rowhammer. There is still a fair bump in cost for ECC system however once you've seen your first syslog entry you forget about the cost. Regardless of rowhammer.
On Wed, Sep 16, 2015 at 11:46:26PM -0400, grarpamp wrote:
Some paper has said systems using ECC RAM are resistant / immune to rowhammer.
There is still a fair bump in cost for ECC system however once you've seen your first syslog entry you forget about the cost. Regardless of rowhammer.
ECC appears controversial: http://blog.erratasec.com/2015/03/some-notes-on-dram-rowhammer.html === Update: This is really just meant as a primer, as background on the issue, not really trying to derive any conclusions. I chatted a bit Chris Evans (@scarybeasts) from google about some of those conclusion, so I thought I'd expand a bit on them. Does ECC protect you? Maybe not. While it will correct single bit flips most of the time, it won't protect when multiple bits flip at once. The hacker may be able to achieve this with enough tries. Remember: the hacker's code can keep retrying this until it succeeds, even if that takes hours. ===
From: Georgi Guninski <guninski@guninski.com> On Wed, Sep 16, 2015 at 11:46:26PM -0400, grarpamp wrote:
Some paper has said systems using ECC RAM are resistant / immune>> to rowhammer. There is still a fair bump in cost for ECC system however once you've seen your first syslog entry you forget about the cost. Regardless of rowhammer. ECC appears controversial: http://blog.erratasec.com/2015/03/some-notes-on-dram-rowhammer.html
Update: This is really just meant as a primer, as background on the i>ssue, not really trying to derive any conclusions. I chatted a bit Chris Evans (@scarybeasts) from google about some of those conclusion, so I thought I'd expand a bit on them.
Does ECC protect you? Maybe not. While it will correct single bit flips most of the time, it won't protect when multiple bits flip at once. Not exactly. Generally, ECC with enough correction bits will at least detect all double-bit errors, although it will not correct those errors. And I can't say for sure how generally this is in use, but I think a competently-designed ECC system will use the regular refresh cycles to "sweep" for correctable single-bit errors, and correct virtually all of them, before they turn into double-bit errors. The hacker may be able to achieve this with enough tries. Remember: the>hacker's code can keep retrying this until it succeeds, even if that>takes hours. However, the profusion of corrected single-bit can be used to alert, and uncorrectable double-bit errors will probably cause a system exception that will inform the system operator that something is going on. Remember, it is likely that different manufacturer's DRAM designs might differ in sensitivity to rowhammer (or other deliberate failure mode) by a factor of 10:1, 100:1, or even 1000:1. The word can, and will, quickly get out what manufacturers sensitivity is, and the market will quickly result in improvement for designs and thus, new systems. Jim Bell
On Thu, Sep 17, 2015 at 05:28:58AM +0000, jim bell wrote:
However, the profusion of corrected single-bit can be used to alert, and uncorrectable double-bit errors will probably cause a system exception that will inform the system operator that something is going on. Remember, it is likely that different manufacturer's DRAM designs might differ in sensitivity to rowhammer (or other deliberate failure mode) by a factor of 10:1, 100:1, or even 1000:1. The word can, and will, quickly get out what manufacturers sensitivity is, and the market will quickly result in improvement for designs and thus, new systems. Jim Bell
You assume sound market, sound buyers and sound users. IMHO these assumptions are false. rowhammer is at least 6 months old. Are there any market changes supporting your claim?
From: grarpamp <grarpamp@gmail.com> On Wed, Sep 16, 2015 at 4:03 PM, jim bell <jdb10987@yahoo.com> wrote:
Product engineers were, and presumably still are, responsible for writing test programs to run chips through their paces, in Intel's case using a Teradyne computer. http://www.teradyne.com/products/semiconductor-test/magnum-v
I don't think the concept of this kind of weakness is new: Even in 1980, DRAMs were tested for such repeated accesses, to ensure that such errors would not occur. This was particularly true for a process called "device characterization", in which chips were attacked in all manner of electronically-abusive ways, to uncover these weaknesses, and fix the circuit design should such flaws be uncovered. One way these techniques could be thwarted is to return to the use of parity-bits (8+1 parity) in memory access, in DRAM module and computer design, to whatever extent they are no longer used. Any (successful) attempt to modify bits in a DRAM would quickly end up causing a parity error, which would at least show which manufacturer's DRAM chips are susceptible to this kind of attack. A person who was forced to use a no-parity computer could, at least, limit his purchases of such modules to those populated with DRAMs not susceptible to the problem. Jim Bell
Some paper has said systems using ECC RAM are resistant / immune to rowhammer. There is still a fair bump in cost for ECC system however once you've seen your first syslog entry you forget about the cost. Regardless of rowhammer. You're right, ECC would be even better. ECC should, indeed, be essentially immune from rowhammer, and will correct it and all other sorts of single-bit errors, and they will generally detect all double-bit errors. However, as you pointed out ECC is presumably much more costly than mere parity bits, not in the least because they have to use more bits of storage. As I vaguely recall, 8 data bits had to be coupled with 4 ECC bits; 16 data/5ECC; 32 data/6 ECC; 64 data/7 ECC; 128 data/8 ECC. This shows that ECC is much more efficient, as word width goes up, which in principle would make its cost penalty easier to take. I haven't been keeping up with DRAM technology like I did in the 70's, 80's, and 90's, but I am not aware if ECC is being easily implemented inside DRAM chips. There was a very early Micron Technology 64Kbit DRAM that, as I recall, had this internal to individual DRAM chips, but it didn't last very long in competition with the jellybean parts. Even more than the cost, I think that ECC added (and maybe still adds) an access-time penalty. Generally, parity-only shouldn't add access time delays. One obscure issue is that if the external memory system detects an error (either parity or ECC), can the microprocessor be instructed to "back up" and reject the recently-acquired byte/word? Most early microprocessors didn't have that ability, which I believe is why those systems had to "wait" for the parity or ECC to be generated and checked. Jim Bell
On Wed, Sep 16, 2015 at 11:46:26PM -0400, grarpamp wrote:
Some paper has said systems using ECC RAM are resistant / immune to rowhammer.
There is still a fair bump in cost for ECC system however once you've seen your first syslog entry you forget about the cost. Regardless of rowhammer.
http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf p. 32 of the PDF: – Simple ECC (e.g., SECDED) cannot prevent all errors From wikipedia: Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word.[1]:8[11]:32 https://en.wikipedia.org/wiki/Row_hammer#cite_ref-isca14-talk_11-0
Some ballyhoo about rowhammer was like "look we can flip a single bit and get root". Obviously if you're going for multibit carnage ECC doesn't help much. https://en.wikipedia.org/wiki/ECC_memory https://en.wikipedia.org/wiki/Hamming_code
From: grarpamp <grarpamp@gmail.com>
Some ballyhoo about rowhammer was like "look we can flip
a single bit and get root". Obviously if you're going for multibit carnage ECC doesn't help much. https://en.wikipedia.org/wiki/ECC_memory https://en.wikipedia.org/wiki/Hamming_code
Again, I must disagree. Rowhammer errors are, presumably, exceedingly rare. But when they do occur, one-bit errors are probably millions of times more common than two-bit errors, which are themselves going too be millions of times more common than three bit errors.. But ECC accesses will automatically correct all one-bit errors, and detect all two-bit errors, and will either log only the 2-bit errors or both single and double-bit errors. I won't try the math, but I suspect that the vast majority of three-bit errors (for 64-bit words) are also detected. Wikipedia says https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Errors%5Fand%5Fer... , "Parity allows the detection of all single-bit errors (actually, any odd number of wrong bits)". So, the smallest number of error bits that might not be detected would be four. Since any serious rowhammer attack will generate millions of correctable single-bit and uncorrectable double- and triple-bit errors, per actual single 4-bit error, any system operator will get a huge amount of warning that the attack is underway before even as many as a single 3-bit error will appear. Jim Bell This came from Wikipedia: https://en.wikipedia.org/wiki/ECC_memory "Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10–10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per millennium, per gigabyte of memory.[4][5][6] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[5] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 2.5–7 × 10−11 error/bit·h) (i.e. about 5 single bit errors in 8 Gigabytes of RAM per hour using the top-end error rate), and more than 8% of DIMM memory modules affected by errors per year. The consequence of a memory error is system-dependent. In systems without ECC, an error can lead either to a crash or to corruption of data; in large-scale production sites, memory errors are one of the most common hardware causes of machine crashes.[5] Memory errors can cause security vulnerabilities.[5] A memory error can have no consequences if it changes a bit which neither causes observable malfunctioning nor affects data used in calculations or saved. A 2010 simulation study showed that, for a web browser, only a small fraction of memory errors caused data corruption, although, as many memory errors are intermittent and correlated, the effects of memory errors were greater than would be expected for independent soft errors.[7] Some tests conclude that the isolation of DRAM memory cells can be circumvented by unintended side effects of specially crafted accesses to adjacent cells. Thus, accessing data stored in DRAM causes memory cells to leak their charges and interact electrically, as a result of high cells density in modern memory, altering the content of nearby memory rows that actually were not addressed in the original memory access. This effect is known as row hammer, and it has also been used in some privilege escalation computer security exploits.[8][9] An example of a single-bit error that would be ignored by a system with no error-checking, would halt a machine with parity checking, or would be invisibly corrected by ECC: a single bit is stuck at 1 due to a faulty chip, or becomes changed to 1 due to background or cosmic radiation; a spreadsheet storing numbers in ASCII format is loaded, and the digit "8" is stored in the byte which contains the stuck bit as its eighth bit; then a change is made to the spreadsheet and it is saved. However, the "8" (00111000 binary) has silently become a "9" (00111001)." [end of Wikipedia quote]
On Fri, Sep 18, 2015 at 06:48:38AM +0000, jim bell wrote:
Since any serious rowhammer attack will generate millions of correctable single-bit and uncorrectable double- and triple-bit errors, per actual single 4-bit error, i any system operator will get a huge amount of warning that the attack is underway before even as many as a single 3-bit error will appear. Jim Bell
In a typical scenario, (unless the admin is quite paranoid and want to DOS themselves), if the exploit works, the logs can be cleared or manipulated, leaving no trace AFAICT. According to some admins I asked...
From: Georgi Guninski <guninski@guninski.com> On Wed, Sep 16, 2015 at 11:46:26PM -0400, grarpamp wrote:
http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf p. 32 of the PDF: .– Simple ECC (e.g., SECDED) cannot prevent all errors From wikipedia: Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word.[1]:8[11]:32 https://en.wikipedia.org/wiki/Row_hammer#cite_ref-isca14-talk_11-0
But all single-bit and triple-bit errors are detectable by parity, and so are all double-bit errors using ECC. https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Errors%5Fand%5Fer... Jim Bell
On Fri, Sep 18, 2015 at 06:54:58AM +0000, jim bell wrote:
From: Georgi Guninski <guninski@guninski.com>
On Wed, Sep 16, 2015 at 11:46:26PM -0400, grarpamp wrote:
http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf p. 32 of the PDF: .– Simple ECC (e.g., SECDED) cannot prevent all errors From wikipedia: Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word.[1]:8[11]:32 https://en.wikipedia.org/wiki/Row_hammer#cite_ref-isca14-talk_11-0
But all single-bit and triple-bit errors are detectable by parity, and so are all double-bit errors using ECC. https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Errors%5Fand%5Fer...
Jim Bell
AFAICT Rowhammer (non-weaponized) publicly appeared in: http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors (from 2014) On p. 8: Therefore, we conclude that SECDED is not failsafe against disturbance errors. Table 5. Uncorrectable multi-bit errors (in bold) Consider publishing your claim as counterexample to the paper (possibly on arxiv.org).
On Wed, Sep 16, 2015 at 08:03:54PM +0000, jim bell wrote:
This brings me back to my stint at Intel, 1980-82, as a new Product Engineer for the 2186, an 8kx8 pseudostatic (self-refreshing dynamic) RAM. (One of the first DRAMs to use redundancy to increase yield.) I may have been the first engineer in the world to see, through a microscope focused on a DRAM chip, a very quick series of flashes, evidence of the programming (blowing) silicon fuses on the chip, to program the row- and column-redundancy information. Product engineers were, and presumably still are, responsible for writing test programs to run chips through their paces, in Intel's case using a Teradyne computer. http://www.teradyne.com/products/semiconductor-test/magnum-v I don't think the concept of this kind of weakness is new: Even in 1980, DRAMs were tested for such repeated accesses, to ensure that such errors would not occur. This was particularly true for a process called "device characterization", in which chips were attacked in all manner of electronically-abusive ways, to uncover these weaknesses, and fix the circuit design should such flaws be uncovered. One way these techniques could be thwarted is to return to the use of parity-bits (8+1 parity) in memory access, in DRAM module and computer design, to whatever extent they are no longer used. Any (successful) attempt to modify bits in a DRAM would quickly end up causing a parity error, which would at least show which manufacturer's DRAM chips are susceptible to this kind of attack. A person who was forced to use a no-parity computer could, at least, limit his purchases of such modules to those populated with DRAMs not susceptible to the problem. Jim Bell
I don't understand hardware and have some questions The POC appears non-deterministic per the nature of the bug. 1. If I run the POC for time X and it fails, does this mean it will fail if I run it for time 100 X? 2. Does increasing the temperature in the box (near or above overheating) increase the chance for success? 3. If you have computer near you, can you induce bit flips on purpose remotely, without executing code on it? (lol, AFAICT if you wait looooong enough cosmic rays will this for you for free, but I am asking about realistic attack).
From: Georgi Guninski <guninski@guninski.com> On Wed, Sep 16, 2015 at 08:03:54PM +0000, jim bell wrote:
I don't think the concept of this kind of weakness is new: Even in 1980, DRAMs were tested for such repeated accesses, to ensure that such >>errors would not occur. This was particularly true for a process called "device characterization", in which chips were attacked in all manner of >>electronically-abusive ways, to uncover these weaknesses, and fix the circuit design should such flaws be uncovered. One way these >>techniques could be thwarted is to return to the use of parity-bits (8+1 parity) in memory access, in DRAM module and computer design, to >>whatever extent they are no longer used. Any (successful) attempt to modify bits in a DRAM would quickly end up causing a parity error, >>which >would at least show which manufacturer's DRAM chips are susceptible to this kind of attack. A person who was forced to use a no->>parity >computer could, at least, limit his purchases of such modules to those populated with DRAMs not susceptible to the problem. >> Jim Bell
I don't understand hardware and have some questions
The POC appears non-deterministic per the nature of the bug. I assume POC means "proof of concept". Yes, the error is non-deterministic. It arises from the fact that bits are stored as different voltages on individual capacitors in a chip, one capacitor per bit. Think of a "0" as being zero volts, 1 is Vcc volts, where Vcc (the supply voltage to the chips) is usually 3 volts. This represents a healthy difference, and could easily be detected. The problem is that the chip can't have one voltage detector for each bit; usually there are about 1048 bits per voltage comparator. When a given row needs to be read, the Row Address line activates, and those 1048 bits are each connected to their corresponding "bit line", which is a tiny electrical conductor with a capacitance much greater than that of the individual bit-cell (capacitor). The resulting voltage difference between a "one" and a "zero" bit might be only a few tens of millivolts, which is rather small. Then, the voltage detector amplifies the voltage difference, to restore it to either GND (0 volts) or Vcc.
1. If I run the POC for time X and it fails, does this mean it will fail if I run it for time 100 X? It's statistical. Probably the number of failures will be approximately proportional to the number of disturb-cycles done.
2. Does increasing the temperature in the box (near or above overheating) increase the chance for>success?
Perhaps just a little. Refreshing of an entire memory array is done once each 64 millisecond. (Used to be 2 millisecond in the 1970s.) It is said that many tens of seconds can elapse before any given bit is disturbed, if refresh is turned off. There should be a lot of margin for loss of refresh, or an inadequate amount of refresh.
3. If you have computer near you, can you induce bit flips on purpose remotely, without executing code on it? (lol, AFAICT if you wait looooong enough cosmic rays will this for you for free, but I am asking about realistic attack). I don't think an external attack (with particles) is plausible.
On Fri, Sep 18, 2015 at 08:34:44AM +0000, jim bell wrote:
3. If you have computer near you, can you induce bit flips on purpose remotely, without executing code on it? (lol, AFAICT if you wait looooong enough cosmic rays will this for you for free, but I am asking about realistic attack). I don't think an external attack (with particles) is plausible.
You well might be right, but attacks only get better... Once upon a time, at an open source party some people claimed that from commodity microwave oven one can made device that (don't remember which of those) damages electronics and/or severely interfere with GSM communications at nontrivial distance. Don't remember the electricity requirements.
On Fri, 18 Sep 2015 16:24:20 +0300 Georgi Guninski <guninski@guninski.com> wrote:
Once upon a time, at an open source party some people claimed that from commodity microwave oven one can made device that (don't remember which of those) damages electronics and/or severely interfere with GSM communications at nontrivial distance.
shouldn't an unshielded microwave oven jam a whole city as well as burn anybody who gets close to it? looks like a great 'terrist' project.
Don't remember the electricity requirements.
ordinary requirements of an ordinary oven?
From: Juan <juan.g71@gmail.com> On Fri, 18 Sep 2015 16:24:20 +0300 Georgi Guninski <guninski@guninski.com> wrote:
Once upon a time, at an open source party some people claimed that from commodity microwave oven one can made device that (don't remember which of those) damages electronics and/or severely interfere with GSM communications at nontrivial distance. shouldn't an unshielded microwave oven jam a whole city as well as burn anybody who gets close to it? looks like a great 'terrist' project.
Within the last couple of months, I think somebody was arrested for planning some sort of "X-ray death ray". http://nypost.com/2015/08/18/kkk-member-built-death-ray-machine-to-kill-musl... But only a dweeb doesn't know that X-rays cannot be focussed. (With one very obscure exception not applicable here. Find it and get an "attaboy!". ) Microwaves, OTOH, can be focussed rather easily. The frequency is 2.45 Ghz, at about 1 Kilowatt. (wavelength about 12 centimeters.) I'd have to consult a Radio Amateur's handbook, but a modern dish (intended or Directv or Dish network) could probably get 15-20 db of gain, compared with isotropic. An old-style 8-foot dish probably would do 30 db gain. That would be 100 kilowatts ERP. Such an unshielded (open) device would probably impair WiFi at 2.5 Ghz severely, if you're close to it, say a few hundred feet away. Fortunately, I think microwave ovens have better than 60 db of shielding. A few 10s of feet, away, hardware damage might occur if that full 1 kw were allowed to leak out. Jim Bell
Don't remember the electricity requirements. ordinary requirements of an ordinary oven? Ordinary microwave ovens are probably 75%-80% efficient. Thus, if you need to supply a 1 kilowatt microwave, you'll probably need 1250 watts of AC power.
On Fri, Sep 18, 2015 at 05:22:40PM -0300, Juan wrote:
Don't remember the electricity requirements.
ordinary requirements of an ordinary oven?
Really don't remember the details. For a simple? device, they needed certain parts. They claimed the easiest way to get the parts was from ordinary microwave oven. Well might be wrong about the electricity requirements.
participants (6)
-
Cathal Garvey -
Georgi Guninski -
grarpamp -
jim bell -
Juan -
The Doctor