RE: [Xen-devel] HT Vulnerability CAN-2005-0109

[Nils Toedtmann <xen-devel@xxxxxxxxxxxxxxxxxx>]

Am Donnerstag, den 19.05.2005, 11:59 +0100 schrieb Ian Pratt: 
>  > At the moment, they release quick workarounds like hardening 
> > crypto libs against timing attacks
> > 
> >   <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157631>
> 
> This is the correct soloution. I was rather shocked to find the crypto
> libs weren't already hardened for such attacks. It's not as though this
> is anything new, just a higher bandwidth version of something that has
> been known about for years.

This sounds like the arguments i once heard "Since we assume xen runs in
a secure envir protected by a properly configured firewall, it's ok that
xend services listen on 0.0.0.0. Since we assume dom0 only has trusted
local users, it's ok that any user can administer domains through xm". I
consider that approach being wrong.

You are right: crypto libs _should_ be resistant against timing attacks.
But an OS _should_ also eliminate side channels if possible as another
line of defense in case there is some userland/domain-kernel which is
not.

BTW: There are timing attacks against symmetric algorithms like AES:

  <http://www.schneier.com/blog/archives/2005/05/aes_timing_atta_1.html>

Does anybody know, if linux' in-kernel encryption (eg. AES for ipsec or
dm-crypt) is resistant against that ...? 


> > or disabling HT
> 
> This is not necessary on Xen. Just allocate domains to CPUs such that
> you don't put potentially non-cooperative domains on the same core. E.g.
> if you're using dom0 just for running the control tool and device
> drivers, just give it one hyperthread and don't allow any other domain
> to use it. This is a pretty sensible way to use HT with Xen anyhow.

Good point! 

Regards, /nils.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel