From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751399AbdJ0FZR (ORCPT ); Fri, 27 Oct 2017 01:25:17 -0400 Received: from ozlabs.org ([103.22.144.67]:57085 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751584AbdJ0FZI (ORCPT ); Fri, 27 Oct 2017 01:25:08 -0400 Date: Fri, 27 Oct 2017 16:25:03 +1100 From: Paul Mackerras To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Christoffer Dall , Marc Zyngier , Christian Borntraeger , Cornelia Huck , James Hogan , kernel-hardening@lists.openwall.com, Kees Cook , Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH v2 0/2] KVM: fixes for the kernel-hardening tree Message-ID: <20171027052503.GB27483@fergus.ozlabs.ibm.com> References: <20171026134547.23664-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171026134547.23664-1-pbonzini@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 26, 2017 at 03:45:45PM +0200, Paolo Bonzini wrote: > Four KVM ioctls (KVM_GET/SET_CPUID2 on x86, KVM_GET/SET_ONE_REG on > ARM and s390) directly access the kvm_vcpu_arch struct. Therefore, the > new usercopy hardening work in linux-next, which forbids copies from and > to slab objects unless they are from kmalloc or explicitly whitelisted, > breaks KVM on those architectures. > > The kvm_vcpu_arch struct is embedded in the kvm_vcpu struct and the > corresponding slab cache is allocated by architecture-independent code. > It is enough, for simplicity, to whitelist the whole sub-struct and > only touch one place of the KVM code. Later, any further restrictions > can be applied in the KVM tree. I checked arch/powerpc/kvm, and all the copy_to/from_user calls are accessing the stack or memory allocated with kzalloc or kvzalloc, so if I understand correctly, we should be OK there. Paul. From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Oct 2017 16:25:03 +1100 From: Paul Mackerras Message-ID: <20171027052503.GB27483@fergus.ozlabs.ibm.com> References: <20171026134547.23664-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171026134547.23664-1-pbonzini@redhat.com> Subject: [kernel-hardening] Re: [PATCH v2 0/2] KVM: fixes for the kernel-hardening tree To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Christoffer Dall , Marc Zyngier , Christian Borntraeger , Cornelia Huck , James Hogan , kernel-hardening@lists.openwall.com, Kees Cook , Radim =?utf-8?B?S3LEjW3DocWZ?= List-ID: On Thu, Oct 26, 2017 at 03:45:45PM +0200, Paolo Bonzini wrote: > Four KVM ioctls (KVM_GET/SET_CPUID2 on x86, KVM_GET/SET_ONE_REG on > ARM and s390) directly access the kvm_vcpu_arch struct. Therefore, the > new usercopy hardening work in linux-next, which forbids copies from and > to slab objects unless they are from kmalloc or explicitly whitelisted, > breaks KVM on those architectures. > > The kvm_vcpu_arch struct is embedded in the kvm_vcpu struct and the > corresponding slab cache is allocated by architecture-independent code. > It is enough, for simplicity, to whitelist the whole sub-struct and > only touch one place of the KVM code. Later, any further restrictions > can be applied in the KVM tree. I checked arch/powerpc/kvm, and all the copy_to/from_user calls are accessing the stack or memory allocated with kzalloc or kvzalloc, so if I understand correctly, we should be OK there. Paul.