In message <[EMAIL PROTECTED]>, "Drew B. [Security Expe
rtise/Freelance Security research]." writes:

>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?

Well, the application could theoretically do something and Colin
advocated it this morning: make the crypto code footprint data
and key independent.  While possible, it is both very tricky to
do (in particular in highlevel languages) and generally found
to be much slower than speed-optimized code.

And while that could solve the immediate panic with OpenSSL and
similar, it does not solve the general problem that you can spy
very efficiently on the behaviour of another program.

The fact that one user would be able to spy on another users editor
application and be able to extract for instance the word lengths
and layout of a document would also be considered a major security
problem in many installations.

Or how about just being able to monitor another customers apache
instance to figure out how much traffic they get and which pages
they get it on ?


The fundamental trouble is that HTT makes the spying far more
efficient than it is with SMP or even UP (I think we are talking
in the order of a million times more efficient). 

That takes the attack from the "if you were really lucky" to the
"almost always in first try" category.

The correct (technical) workaround (IMO) is to restrict HTT to be
used only for threads from the same process.

The political problem is that if all operating systems do that,
Intel has a pretty dud feature on their hands, and they are not
particularly eager to accept that fact.

Poul-Henning

-- 
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.
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
  • FreeBSD Security... FreeBSD Security Advisories
    • Re: FreeBSD... David Schultz
      • Re: Fre... Poul-Henning Kamp
        • Re:... Drew B. [Security Expertise/Freelance Security research].
          • ... Poul-Henning Kamp
            • ... Drew B. [Security Expertise/Freelance Security research].
              • ... Chris
                • ... Colin Percival
                • ... Poul-Henning Kamp
                • ... Jason Stone
            • ... Garrett Wollman
              • ... Poul-Henning Kamp
            • ... Dag-Erling Smørgrav
            • ... David Schultz
              • ... Colin Percival

Reply via email to