[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.