Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp770874ybb; Fri, 20 Mar 2020 07:50:51 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuAPY3lQ6Ce/ft7iD/nIUY2j0ox7w2/fpM0YwnpTF4V2xPBjcVbflk1imRigeCSXxG+SNyU X-Received: by 2002:a9d:a68:: with SMTP id 95mr6718190otg.87.1584715851658; Fri, 20 Mar 2020 07:50:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584715851; cv=none; d=google.com; s=arc-20160816; b=ksXGfnNKXgWsB31iWsJMwqeeghuJz5+QMP5cMgZI1cHrkpTi/pzkbRmOVGPUFnloI2 61nsI3wtvWC5lOZVyo2kEKii6yO9yqx5GvEI/FbCne760V7x+zOwVV0/3BnbcCa3NIKf XjRXC6n3f9kOsaCFZRA9aqRKwP6E+qCo1gjLpa2tSAFgg5i1O845uduQ5htHDACjGPn/ W2sab7U/qOgvHVK3MKgGozVD4OPja65RmEL67xaW2JY4gm3kdsfaNEUbsL0YYZsygCUw RJvqHVwjgLsqK/Auhz+9B9AhaELVXV+86DJewLjQVy1cv35qhrX2EojCgmuSZsVyxxR1 DvWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=VIcWGulvE3FbFgsCzxYiCgq24rzJamdJAngiP+hOagI=; b=RZP5h/t33gQXB90ugmwaj7WxIpmxMm5RKBZDhWQSeoqz/JfEwduX5QQVaRqACtpdhX hNyxefzCe9gqH7LNIVF9sVWj3q07SLK6teROG++/2Mu+psACwrwfhl8KnFMACdFzFgEK doBfIh4M+JB8I5/DBX3ctZQz1YmySpY6wpT1imERT+1P5GHXDMrc/n8zS7r3hnx3pj5m 1C2FUko0ib0hTrh5Cbkrvv6yJlmdqBLnVivqW1DgO7HzAT6Sq00vsqMxRGfoPGV0dNpQ JJK6OY3Ie5px0kqnEF0duMAJ/gzidAvxeBPvu6JRaaZ11ZW3d0/7YevTDRIJ1D66Q/jJ DvYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l131si2952541oih.10.2020.03.20.07.50.39; Fri, 20 Mar 2020 07:50:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727145AbgCTOuV (ORCPT + 99 others); Fri, 20 Mar 2020 10:50:21 -0400 Received: from 7.mo173.mail-out.ovh.net ([46.105.44.159]:33852 "EHLO 7.mo173.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726840AbgCTOuV (ORCPT ); Fri, 20 Mar 2020 10:50:21 -0400 X-Greylist: delayed 8434 seconds by postgrey-1.27 at vger.kernel.org; Fri, 20 Mar 2020 10:50:19 EDT Received: from player728.ha.ovh.net (unknown [10.110.208.160]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id A6375135FBD for ; Fri, 20 Mar 2020 13:23:05 +0100 (CET) Received: from kaod.org (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player728.ha.ovh.net (Postfix) with ESMTPSA id 060EF108AE6BD; Fri, 20 Mar 2020 12:22:49 +0000 (UTC) Date: Fri, 20 Mar 2020 13:22:48 +0100 From: Greg Kurz To: Laurent Dufour Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kvm-ppc@vger.kernel.org, Bharata B Rao , Paul Mackerras , Benjamin Herrenschmidt , Michael Ellerman Subject: Re: [PATCH 1/2] KVM: PPC: Book3S HV: check caller of H_SVM_* Hcalls Message-ID: <20200320132248.44b81b3b@bahia.lan> In-Reply-To: <20200320102643.15516-2-ldufour@linux.ibm.com> References: <20200320102643.15516-1-ldufour@linux.ibm.com> <20200320102643.15516-2-ldufour@linux.ibm.com> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 13089993795129285060 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeguddgfeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfgjfhfogggtgfesthejredtredtvdenucfhrhhomhepifhrvghgucfmuhhriicuoehgrhhouhhgsehkrghougdrohhrgheqnecukfhppedtrddtrddtrddtpdekvddrvdehfedrvddtkedrvdegkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejvdekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepghhrohhugheskhgrohgurdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhg Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Mar 2020 11:26:42 +0100 Laurent Dufour wrote: > The Hcall named H_SVM_* are reserved to the Ultravisor. However, nothing > prevent a malicious VM or SVM to call them. This could lead to weird result > and should be filtered out. > > Checking the Secure bit of the calling MSR ensure that the call is coming > from either the Ultravisor or a SVM. But any system call made from a SVM > are going through the Ultravisor, and the Ultravisor should filter out > these malicious call. This way, only the Ultravisor is able to make such a > Hcall. "Ultravisor should filter" ? And what if it doesn't (eg. because of a bug) ? Shouldn't we also check the HV bit of the calling MSR as well to disambiguate SVM and UV ? > > Cc: Bharata B Rao > Cc: Paul Mackerras > Cc: Benjamin Herrenschmidt > Cc: Michael Ellerman > Signed-off-by: Laurent Dufour > --- > arch/powerpc/kvm/book3s_hv.c | 32 +++++++++++++++++++++----------- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c > index 33be4d93248a..43773182a737 100644 > --- a/arch/powerpc/kvm/book3s_hv.c > +++ b/arch/powerpc/kvm/book3s_hv.c > @@ -1074,25 +1074,35 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu) > kvmppc_get_gpr(vcpu, 6)); > break; > case H_SVM_PAGE_IN: > - ret = kvmppc_h_svm_page_in(vcpu->kvm, > - kvmppc_get_gpr(vcpu, 4), > - kvmppc_get_gpr(vcpu, 5), > - kvmppc_get_gpr(vcpu, 6)); > + ret = H_UNSUPPORTED; > + if (kvmppc_get_srr1(vcpu) & MSR_S) > + ret = kvmppc_h_svm_page_in(vcpu->kvm, > + kvmppc_get_gpr(vcpu, 4), > + kvmppc_get_gpr(vcpu, 5), > + kvmppc_get_gpr(vcpu, 6)); If calling kvmppc_h_svm_page_in() produces a "weird result" when the MSR_S bit isn't set, then I think it should do the checking itself, ie. pass vcpu. This would also prevent adding that many lines in kvmppc_pseries_do_hcall() which is a big enough function already. The checking could be done in a helper in book3s_hv_uvmem.c and used by all UV specific hcalls. > break; > case H_SVM_PAGE_OUT: > - ret = kvmppc_h_svm_page_out(vcpu->kvm, > - kvmppc_get_gpr(vcpu, 4), > - kvmppc_get_gpr(vcpu, 5), > - kvmppc_get_gpr(vcpu, 6)); > + ret = H_UNSUPPORTED; > + if (kvmppc_get_srr1(vcpu) & MSR_S) > + ret = kvmppc_h_svm_page_out(vcpu->kvm, > + kvmppc_get_gpr(vcpu, 4), > + kvmppc_get_gpr(vcpu, 5), > + kvmppc_get_gpr(vcpu, 6)); > break; > case H_SVM_INIT_START: > - ret = kvmppc_h_svm_init_start(vcpu->kvm); > + ret = H_UNSUPPORTED; > + if (kvmppc_get_srr1(vcpu) & MSR_S) > + ret = kvmppc_h_svm_init_start(vcpu->kvm); > break; > case H_SVM_INIT_DONE: > - ret = kvmppc_h_svm_init_done(vcpu->kvm); > + ret = H_UNSUPPORTED; > + if (kvmppc_get_srr1(vcpu) & MSR_S) > + ret = kvmppc_h_svm_init_done(vcpu->kvm); > break; > case H_SVM_INIT_ABORT: > - ret = kvmppc_h_svm_init_abort(vcpu->kvm); > + ret = H_UNSUPPORTED; > + if (kvmppc_get_srr1(vcpu) & MSR_S) > + ret = kvmppc_h_svm_init_abort(vcpu->kvm); > break; > > default: