Date: Sat, 14 May 2005 08:06:30 +0100 From: Chris <chrcoluk@gmail.com> To: "Drew B. [Security Expertise/Freelance Security research]." <d4rkstorm@gmail.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] Message-ID: <3aaaa3a050514000629cc8427@mail.gmail.com> In-Reply-To: <245f0df105051322354e8e86eb@mail.gmail.com> References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> <245f0df105051322354e8e86eb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I am somewhat confused by applying the patch, does this disable HTT functionality? or does a patched server close the issue and keep HTT enabled? Chris On 5/14/05, Drew B. [Security Expertise/Freelance Security research]. <d4rkstorm@gmail.com> wrote: > 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. >=20 > Hehehe... I cannot help but giigle abit, I didnt think this went that > deep :o , definately interesting stuff regarding the future of HT and > O/S Types,ty even though the answer may help someone else more, > Regards, > Drew B. >=20 > (Enlightening myself to inspire others is my answer to everything *No-Com= ment*) >=20 >=20 > On 5/14/05, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: > > In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Secur= ity 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 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompete= nce. > > >=20 > -- > -------------------------------------------------------------------- > Drew B. > Independant Security analysis,for Aussies. > Security researcher/expert,threat-focus,Freelance. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3aaaa3a050514000629cc8427>