So this sounds like trying to solve in the OS a problem that can only be solved in the application. Is there something more subtle that's going on?
-> This is a strange but interesting problem, if indeed the SMT is not 'needed' , then perhaps there is something more malicious in the code, (Internally), wich may need more corrections and addressing directly,the FreeBSD team I am sure will know what todo,Im merely suggesting a method. I cannot see an immediate threat,but wouldnt looking into the source code abit more perhaps and see whats going on,and also perhaps some more specifics from that SunOS test would be useful,some info so that the actual multiple memory cache problem itself could be addressed on its own to begin with,localise the problem perhaps, then dissect? Anyhow just a suggestion, It is not really my area so i should poke my nose out now :) Regards, Drew B. On 5/14/05, Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > In message <[EMAIL PROTECTED]>, David Schultz writes: > > >But isn't this a well-known and fundamental problem with SMT? > > Yes. > > The news being only the speed: you can get 300 bits of the 512 bit > RSA key in a single observation of a single shot run of the crypto. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- -------------------------------------------------------------------- Drew B. Independant Security analysis,for Aussies. Security researcher/expert,threat-focus,Freelance. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[EMAIL PROTECTED]"
