[ovirt-users] KSM and cross-vm attack

[Doron Fediuck]

----- Original Message -----
> From: "Dan Kenigsberg" <danken at redhat.com>
> To: "Jorick Astrego" <j.astrego at netbulae.eu>, alitke at redhat.com, doron at redhat.com
> Cc: users at ovirt.org
> Sent: Friday, June 13, 2014 1:36:17 PM
> Subject: Re: [ovirt-users] KSM and cross-vm attack
> 
> On Fri, Jun 13, 2014 at 11:05:37AM +0200, Jorick Astrego wrote:
> > Hi Sven,
> > 
> > Thanks for you response, I will read some more.
> > 
> > But as you say it has been known for a while and I was aware of it for many
> > years although never diving into the specifics. I always thought it was not
> > a practical attack vector
> > 
> > What caught my attention was that it was so fast it can be done in less
> > then
> > a minute:
> > 
> >    Lightning-Fast Attack: *Even in the worst case scenario (cross-VM)
> >    the attack**
> >    **succeeds in less than a minute. To the best of our knowledge, no
> >    faster attack**
> >    **has been implemented against AES in a realistic cloud-like
> >    setting. This also**
> >    **means that just one minute of co-location with the encryption
> >    server suffices to**
> >    **recover the key.*
> > 
> > 
> > >For the most parts, it's easier to hack you machine directly
> > >or social-engineer your way into it, than it is to hack/get
> > >access to a different vm on the same system and than hack another vm.
> > 
> > So that was the part that worries me, if I have a public cloud offering and
> > someone doesn't hack a vm but simply rents one. He can then spawn a new VM
> > every couple of minutes and it will probably be on a different host each
> > time..... with different neighbours.
> > 
> > You could hack every vulnerable customer VM in a couple of hours this way
> > and it would all be undetected.
> > 
> > >There are also still no automatic tools for this, which I'm aware of
> > >(if they are, I'd like to be pointed to them).
> > >
> > >As soon as automatic attack tools will cover this scenario I'm pretty
> > >sure we'll see an increase in hacked vms and sniffed private keys.
> > I'm sure there are automatic tools being built as we speak but they will
> > not
> > be generally available.
> 
> It would be relatively simple to disable KSM per VM. This way, a
> customer that values security more than density, could pay more to keep
> his memory pages unscanned by KSM.
> 
> Anyone cares to open an RFE for that? I remember that the idea was
> discussed, but I do not find a formal bug that tracks this.

Indeed we had an old bz for it. A brand new ovirt RFE will help.
Also, it is possible to disable ksm for a cluster today. So it's already possible
to have an optimized cluster and a more strict one in the same DC.