SLE11-SP1-TD is obviously missing 6d77dbfc88e3 (KVM: inject #UD if instruction emulation fails and exit to userspace). I guess we want it as well as it is providing a common error handling for more paths. The patch however removes kvm_report_emulation_failure which is exported for modules and thus breaks the kABI.

Joerg could you help me out please? Maybe we need the fix only for the emulation path?

Btw. this seems to be a duplicate of bug 905312. The other bug mentions two commits and has a different CVE number so I am not closing it as such. Maybe the other bug should care only about a2b9e6c1a35a (KVM: x86: Don't report guest userspace emulation error to userspace)

(In reply to Michal Hocko from comment #3)
> SLE11-SP1-TD is obviously missing 6d77dbfc88e3 (KVM: inject #UD if
> instruction emulation fails and exit to userspace). I guess we want it as
> well as it is providing a common error handling for more paths. The patch
> however removes kvm_report_emulation_failure which is exported for modules
> and thus breaks the kABI.
> 
> Joerg could you help me out please? Maybe we need the fix only for the
> emulation path?

I think we can apply the patch and keep kvm_report_emulation_failure around. I'll try to come up with a patch for SLE11-SP1-TD.

On the other hand, this issue is only about nested virtualization (which is only implemented for SVM in the SLE11-SP1-TD kernel).

This kernel has a lot of other security problems in nested virt, so we could also just disable this feature permanently and be safe again.

The kernel has also no support for nested NPT, so that any L2 guest will be very slow anyway, I doubt that anyone uses this feature in production.

Opinions?

(In reply to Joerg Roedel from comment #6)
> On the other hand, this issue is only about nested virtualization (which is
> only implemented for SVM in the SLE11-SP1-TD kernel).
> 
> This kernel has a lot of other security problems in nested virt, so we could
> also just disable this feature permanently and be safe again.

Good point. I am pretty sure that nested virtualization is not supported by us in any means, especially in SLE11, right?

(In reply to Jiri Kosina from comment #7)
> (In reply to Joerg Roedel from comment #6)
> > On the other hand, this issue is only about nested virtualization (which is
> > only implemented for SVM in the SLE11-SP1-TD kernel).
> > 
> > This kernel has a lot of other security problems in nested virt, so we could
> > also just disable this feature permanently and be safe again.
> 
> Good point. I am pretty sure that nested virtualization is not supported by
> us in any means, especially in SLE11, right?

I would be very surprised if it is supported. SUSE would be the first company I know of that support nested virt in any product :)

Also the nested virt code is still pretty experimental in 2.6.32.

(In reply to Jiri Kosina from comment #7)
> (In reply to Joerg Roedel from comment #6)
> > On the other hand, this issue is only about nested virtualization (which is
> > only implemented for SVM in the SLE11-SP1-TD kernel).
> > 
> > This kernel has a lot of other security problems in nested virt, so we could
> > also just disable this feature permanently and be safe again.
> 
> Good point. I am pretty sure that nested virtualization is not supported by
> us in any means, especially in SLE11, right?

Nested virtualization is certainly not supported in SP1, and has been tech preview for SP3 and still for SLE12.

I would be fine with it being disabled for the TD kernel, if TD also agrees.

(In reply to Joerg Roedel from comment #12)
> (In reply to roberto angelino from comment #11)
> > (In reply to Michal Hocko from comment #9)
> > > Let's add Roberto to get TD opinion on that. See the last three comments.
> > 
> > Just to be clear, we are talking about sles11.sp1 KVM guest(s) here right?
> 
> No, the bug affects sles11.sp1 kvm host(s).

The environment that Teradata will be using in kvm is sles11 sp3 hosts with sles11 sp1 guests.  Now that's not to say a customer can do something stupid like run kvm on a sles11 sp1 host.  What exactly are we proposing to disable so the CVE would be invalid?  Because in the past even if they don't use a particular sles feature and a CVE is against it, they ask for the fix anyway since a customer who could potentially use it, can use it and then they are vulnerable.

(In reply to Roberto Angelino from comment #13)

> The environment that Teradata will be using in kvm is sles11 sp3 hosts with
> sles11 sp1 guests.  Now that's not to say a customer can do something stupid
> like run kvm on a sles11 sp1 host.  What exactly are we proposing to disable
> so the CVE would be invalid?  Because in the past even if they don't use a
> particular sles feature and a CVE is against it, they ask for the fix anyway
> since a customer who could potentially use it, can use it and then they are
> vulnerable.

If TD only runs sles11-sp1 in KVM guests there is a very high chance they are not using KVM on that platform at all (as that would already be nested virtualization, which is not supported by us). Also the plan is to disable nested-virt completly, so that it could not be re-enabled by the user.

(In reply to Joerg Roedel from comment #12)
> (In reply to roberto angelino from comment #11)
> > (In reply to Michal Hocko from comment #9)
> > > Let's add Roberto to get TD opinion on that. See the last three comments.
> > 
> > Just to be clear, we are talking about sles11.sp1 KVM guest(s) here right?
> 
> No, the bug affects sles11.sp1 kvm host(s).

OK.  The issue is against sles11 sp1 kvm host which I KNOW they don't use, BUT that doesn't mean they won't want the CVE.  Let me ask them.

Teradata says they do not want to disable kvm.  And they do want the patch even though they do not support sles11.sp1 kvm hosts configuration.

(In reply to Roberto Angelino from comment #16)
> Teradata says they do not want to disable kvm.  And they do want the patch
> even though they do not support sles11.sp1 kvm hosts configuration.

Jut to be clear, my comment #10 was about disabling in the SP1 TD kernel the ability do do nested virtualization, not to disable kvm entirely. Not that I am determined that that is the appropriate solution, but since it had been mentioned in comment #6 as an option, I chimed in agreeing that that would be a fairly easy way to avoid all nested virtualization security vulnerabilities in the TD kernel.

I think it's a very good and safe choice to disable nested virt. In fact, isn't it disabled by default with a module option in SP1 still?

In that case, users will have to proactively enable a known-broken, known-insecure, unsupported feature to ever run into this security problem.

(In reply to Alexander Graf from comment #18)
> I think it's a very good and safe choice to disable nested virt. In fact,
> isn't it disabled by default with a module option in SP1 still?
> 
> In that case, users will have to proactively enable a known-broken,
> known-insecure, unsupported feature to ever run into this security problem.

In SP1, only svm does nested virtualization, and it was enabled by default.

Ah, Jörg enabled it by default back in 2.6.32 with commit 4b6e4dca701. If we simply revert that commit I think we're set.

Okay, for now I backported the following commits to the SLE11-SP1-TD branch:

6d77dbfc KVM: inject #UD if instruction emulation fails and exit to userspace
ec9e60b2 KVM: X86: Introduce generic guest-mode representation
2030753d KVM: SVM: Make Use of the generic guest-mode functions
fc3a9157 KVM: X86: Don't report L2 emulation failures to user-space
a2b9e6c1 KVM: x86: Don't report guest userspace emulation error to userspace

This are the patches with their prerequisites to fix CVE-2010-5313 and the related CVE-2014-7842.

This should be what TD requested. Nevertheless I still suggest to permanently disable nested virtualization on that kernel, as there are other problems left.

The patches are only compile-tested so far, I'll try to give them some runtime testing too to check if KVM still works. Especially the backport of the first patch turned out to be ugly and complicated and I want to make sure it does not break everything.

(In reply to Joerg Roedel from comment #21)
> Okay, for now I backported the following commits to the SLE11-SP1-TD branch:
> 
> 6d77dbfc KVM: inject #UD if instruction emulation fails and exit to userspace
> ec9e60b2 KVM: X86: Introduce generic guest-mode representation
> 2030753d KVM: SVM: Make Use of the generic guest-mode functions
> fc3a9157 KVM: X86: Don't report L2 emulation failures to user-space
> a2b9e6c1 KVM: x86: Don't report guest userspace emulation error to userspace
> 
> This are the patches with their prerequisites to fix CVE-2010-5313 and the
> related CVE-2014-7842.
> 
> This should be what TD requested. Nevertheless I still suggest to
> permanently disable nested virtualization on that kernel, as there are other
> problems left.

Joerg,
   I talked to Qiyan & he's OK with disabling nested virtualization.  But I need Milad's OK.  He's out to lunch right now.  I'll update the bug once I talk to him.

> > This should be what TD requested. Nevertheless I still suggest to
> > permanently disable nested virtualization on that kernel, as there are other
> > problems left.
> 
> Joerg,
>    I talked to Qiyan & he's OK with disabling nested virtualization.  But I
> need Milad's OK.  He's out to lunch right now.  I'll update the bug once I
> talk to him.

Milad says he's ok also with compiling out nested virtualization in their sles11.sp1 kernel.  Only thing is we have to reference the CVE & comment it in changelog so their customer service reps can check if anyone queries about it.

Thanks

pushed to SLE11-SP1-TD. Thanks a lot Joerg!

released

SUSE-SU-2015:0652-1: An update that solves 17 vulnerabilities and has 10 fixes is now available.

Category: security (important)
Bug References: 771619,833820,846404,857643,875051,885077,891211,892235,896390,896391,896779,899338,902346,902349,902351,904700,905100,905312,907822,908870,911325,912654,912705,912916,913059,915335,915826
CVE References: CVE-2010-5313,CVE-2012-6657,CVE-2013-4299,CVE-2013-7263,CVE-2014-0181,CVE-2014-3184,CVE-2014-3185,CVE-2014-3673,CVE-2014-3687,CVE-2014-3688,CVE-2014-7841,CVE-2014-7842,CVE-2014-8160,CVE-2014-8709,CVE-2014-9420,CVE-2014-9584,CVE-2014-9585
Sources used:
SUSE Linux Enterprise Server 11 SP1 LTSS (src):    kernel-default-2.6.32.59-0.19.1, kernel-ec2-2.6.32.59-0.19.1, kernel-pae-2.6.32.59-0.19.1, kernel-source-2.6.32.59-0.19.1, kernel-syms-2.6.32.59-0.19.1, kernel-trace-2.6.32.59-0.19.1, kernel-xen-2.6.32.59-0.19.1, xen-4.0.3_21548_18-0.9.17
SLE 11 SERVER Unsupported Extras (src):    kernel-default-2.6.32.59-0.19.1, kernel-pae-2.6.32.59-0.19.1, kernel-xen-2.6.32.59-0.19.1