Re: [Cryptography] Super-computer project wanted
dave@horsfall.org So, is there anything that could benefit from a few parallel teraflops here and there?
On Tue, Jul 14, 2015 at 12:27 PM, Ray Dillinger <bear@sonic.net> wrote:
Or you could apply static code analysis software to huge masses of existing operating system, device driver, plugin, email-client or god-help-us browser code in wide use and see if you can't spot instances of dangerous vulnerabilities like buffer overflows. A list of known errors would be very helpful in getting code up to 'bulletproof' reliability and no one runs ALL the possible static analysis we know about on large bodies of code because it takes too long on regular computers.
This, and fuzzing... of all the opensource OS's and all the ported packages they supply. And dump all of github in it for fun. It takes too long, too much developer time, a different skillset, opensource test suites may not yet cover some areas that commercial ones do, etc. Ripe for development of an open perpetual audit project. That, and printing your own open and trusted chips, in your own open and trusted fab, are possible now. It's big picture, grand slam, full circle headiness, but it is doable. People just have to get together and kick it off.
On 15/07/15 08:44, grarpamp wrote:
dave@horsfall.org So, is there anything that could benefit from a few parallel teraflops here and there?
On Tue, Jul 14, 2015 at 12:27 PM, Ray Dillinger <bear@sonic.net> wrote:
Or you could apply static code analysis software to huge masses of existing operating system, device driver, plugin, email-client or god-help-us browser code in wide use and see if you can't spot instances of dangerous vulnerabilities like buffer overflows. A list of known errors would be very helpful in getting code up to 'bulletproof' reliability and no one runs ALL the possible static analysis we know about on large bodies of code because it takes too long on regular computers.
This, and fuzzing... of all the opensource OS's and all the ported packages they supply. And dump all of github in it for fun.
FYI, the AFL fuzzer already have an impressing trophy case: See "The bug-o-rama trophy case" at http://lcamtuf.coredump.cx/afl/
It takes too long, too much developer time, a different skillset, opensource test suites may not yet cover some areas that commercial ones do, etc.
Ripe for development of an open perpetual audit project.
That, and printing your own open and trusted chips, in your own open and trusted fab, are possible now. It's big picture, grand slam, full circle headiness, but it is doable. People just have to get together and kick it off.
On 15/07/15 11:42, Christian Gagneraud wrote:
On 15/07/15 08:44, grarpamp wrote:
dave@horsfall.org So, is there anything that could benefit from a few parallel teraflops here and there?
On Tue, Jul 14, 2015 at 12:27 PM, Ray Dillinger <bear@sonic.net> wrote:
Or you could apply static code analysis software to huge masses of existing operating system, device driver, plugin, email-client or god-help-us browser code in wide use and see if you can't spot instances of dangerous vulnerabilities like buffer overflows. A list of known errors would be very helpful in getting code up to 'bulletproof' reliability and no one runs ALL the possible static analysis we know about on large bodies of code because it takes too long on regular computers.
This, and fuzzing... of all the opensource OS's and all the ported packages they supply. And dump all of github in it for fun.
FYI, the AFL fuzzer already have an impressing trophy case: See "The bug-o-rama trophy case" at http://lcamtuf.coredump.cx/afl/
And here is a blog post about the future of the Linux Trinity fuzzer, used by Hacking Team to fuzz Android IOCTL. "I’m done enabling assholes." http://codemonkey.org.uk/2015/07/12/future-trinity/ Chris
It takes too long, too much developer time, a different skillset, opensource test suites may not yet cover some areas that commercial ones do, etc.
Ripe for development of an open perpetual audit project.
That, and printing your own open and trusted chips, in your own open and trusted fab, are possible now. It's big picture, grand slam, full circle headiness, but it is doable. People just have to get together and kick it off.
On Thu, Jul 16, 2015 at 10:46:58AM +1200, Christian Gagneraud wrote:
On 15/07/15 11:42, Christian Gagneraud wrote:
On 15/07/15 08:44, grarpamp wrote:
dave@horsfall.org So, is there anything that could benefit from a few parallel teraflops here and there?
On Tue, Jul 14, 2015 at 12:27 PM, Ray Dillinger <bear@sonic.net> wrote:
Or you could apply static code analysis software to huge masses of existing operating system, device driver, plugin, email-client or god-help-us browser code in wide use and see if you can't spot instances of dangerous vulnerabilities like buffer overflows. A list of known errors would be very helpful in getting code up to 'bulletproof' reliability and no one runs ALL the possible static analysis we know about on large bodies of code because it takes too long on regular computers.
This, and fuzzing... of all the opensource OS's and all the ported packages they supply. And dump all of github in it for fun.
FYI, the AFL fuzzer already have an impressing trophy case: See "The bug-o-rama trophy case" at http://lcamtuf.coredump.cx/afl/
And here is a blog post about the future of the Linux Trinity fuzzer, used by Hacking Team to fuzz Android IOCTL.
"I’m done enabling assholes."
http://codemonkey.org.uk/2015/07/12/future-trinity/
Chris
It takes too long, too much developer time, a different skillset, opensource test suites may not yet cover some areas that commercial ones do, etc.
Ripe for development of an open perpetual audit project.
That, and printing your own open and trusted chips, in your own open and trusted fab, are possible now. It's big picture, grand slam, full circle headiness, but it is doable. People just have to get together and kick it off.
I think the only way this is going to work is if there is a business model based on small, medium, and large scale business ecosystems selling open source hardware [1][2], and these businesses differentiate themselves by the amount and types of fuzzing they do on the whole damn system. [1] http://search.proquest.com/openview/317778ee503bb0624c7b51c868833bd0/1?pq-or... [2] http://gplspace.org/
participants (3)
-
Christian Gagneraud -
grarpamp -
Troy Benjegerdes