3 ms·
One implementation of a single-event-upset testbed that I worked with used the valgrind infrastructure to inject faults in running code, purely in software. (E
by mturmon 11y ago
One implementation of a single-event-upset testbed that I worked with used the valgrind infrastructure to inject faults in running code, purely in software. (Example: http://www.sts.tu-harburg.de/research/fitin.html http://www.sts.tu-harburg.de/research/fitin.html, earlier work: http://dus.jpl.nasa.gov/projects/solar/Papers/granat-abft-svm-09.pdf http://dus.jpl.nasa.gov/projects/solar/Papers/granat-abft-sv...)
Your larger point is right: some commenters are giving up on problem analysis or solutions "because the problem is hardware". That implication does not follow. Perhaps people are too used to highly abstracted software systems?
- sickbeard 11y agoI think you guys just misunderstand. The question you should be asking should be "is this this right solution", rather than "can this be done?". If you want to build robust systems, picking the right solution is paramount. In this case the consensus seems to be to fix it in hardware rather than messing out with software (it takes longer to implement a verifiable solution, harder to test, etc).
- mturmon 11y agoI wrote to push back against some sweeping claims that are made nearby, such as "if the hardware is bad, your software will be bad." This is simply not true for many values of "bad". Another comment nearby regarding testing also surrendered prematurely. I worked and published in the area for a few years, so I have a definite POV. I find it appealing that software can, in some cases, make up for the failings of hardware. The topic area is fascinating. It has some of the intellectual aspects of security research: you can get somewhere by breaking through abstraction barriers in surprising ways.