Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp894023ybb; Fri, 3 Apr 2020 13:56:45 -0700 (PDT) X-Google-Smtp-Source: APiQypI/y3Jhl2+bVw2iM9Ta5Z4CDrv8KeiIS8EkrN41HVNPFkV1J+9ikhMLkTM/c7sX0u7opeeW X-Received: by 2002:a05:6830:239b:: with SMTP id l27mr8176121ots.278.1585947404807; Fri, 03 Apr 2020 13:56:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585947404; cv=none; d=google.com; s=arc-20160816; b=dQkJr244Woe5rDTI2q/mT7iXFO44dd4jsSrDAoaNY5k6GHmIcHQ3YxLLHJW4iP/kll nNqjDFjmuXpZpK1dvzMuhbf2xH/cV/HN+Q0DKSX4I+JljMZ79Am0UanwxctoKhsD1sTm OA6xuGnnB4LkuOSUuE3X+mlUr4yY9bDkju9cYbUqg8mWsbXxEak38A0Z74lf86sQ5U0O sKXxLLE/IYrYsusYGy8A5h+iXsQIkUNaVy/UEtmkpyeaU3ArZTKg/klQO3OG39lDuC0d McjabFXWU0EU+bsFt5RbGY5Tz8FscFbP+u+7xPO0bTE42NMqqRgLiaP5Nggb/6buA4gO AE5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=CuzkNlfbQV3GkYQd8LWFwAKjg5VuiknSmYb1iJXUVP8=; b=xbdsIF8gEL5dO+sb9ZI2FB1mTIku9WR6pbvkKNne3WkB/VDi2S/TkLocZcEaF2eTBp D5YTe835wtONnyzhiGxgl/zxa2c2LJx9W3O4KMfmqRixBQXevXZnQvkxfT9gcjSoJV6T 5uObv+HVSkY9iohcUpv0VSXWdr9dCOd+cbnf4S7hAAY6mP98t5cT0oX68+QJoa3grMmP oztqUZ78PZ6EE2uKW9E4//bFLBoYWrWk3D2UWTcAPQidyUo05cyo7/ki2W13e9lDe+bq ILyBQQ8NQlqahjoLlQszwYRPdjmxTsbM4VF84eQeezOpIs5Hu7V0etAi6s0BqSNoNiQ1 +OXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=XVEi+SWR; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m205si4116258oib.116.2020.04.03.13.56.30; Fri, 03 Apr 2020 13:56:44 -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; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=XVEi+SWR; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728268AbgDCUzj (ORCPT + 99 others); Fri, 3 Apr 2020 16:55:39 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:56900 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726368AbgDCUzj (ORCPT ); Fri, 3 Apr 2020 16:55:39 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 033KhISF091448; Fri, 3 Apr 2020 20:55:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=corp-2020-01-29; bh=CuzkNlfbQV3GkYQd8LWFwAKjg5VuiknSmYb1iJXUVP8=; b=XVEi+SWRNcVLJVwyIXEpA/maN8eab+ogjaMgTBfb4PpKqHCmPcwoQJ3ZTdjPQd9ASCRt HsAHev1q5j9KPyEDXwDZ7G+Pjfg3Ry8h0SWlh+zP9ovkC8D1lRBPFFj93A6TDpl3BVPg TB1WEris1dv8jx3uMeBqZ1/YCAzz/OsFErgsWvEl5CoYaoVFVS7dshFVwVsqRco/qUJn lpCjcjbhPvjZ8FK8cGqfMRFGkCoLb8p5Lc2FZvbNhKN6waDxsY6Ia79dmz15QIAaCQIv /VrwPAqEDkHooYkX2to3R4gosJus09g+T4uP9ZTtMhIXrPg6q/rJjn+JW+VxdlsG4rDe ow== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 303aqj3ns6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Apr 2020 20:55:18 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 033Kh3xj187999; Fri, 3 Apr 2020 20:55:17 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3030.oracle.com with ESMTP id 302g2nx3vs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 03 Apr 2020 20:55:17 +0000 Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 033KtDqg015975; Fri, 3 Apr 2020 20:55:14 GMT Received: from vbusired-dt (/10.154.116.130) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 03 Apr 2020 13:55:13 -0700 Date: Fri, 3 Apr 2020 15:55:07 -0500 From: Venu Busireddy To: Krish Sadhukhan Cc: Ashish Kalra , pbonzini@redhat.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, joro@8bytes.org, bp@suse.de, thomas.lendacky@amd.com, x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, rientjes@google.com, srutherford@google.com, luto@kernel.org, brijesh.singh@amd.com Subject: Re: [PATCH v6 09/14] KVM: x86: Introduce KVM_GET_PAGE_ENC_BITMAP ioctl Message-ID: <20200403205507.GA729294@vbusired-dt> References: <388afbf3af3a10cc3101008bc9381491cc7aab2f.1585548051.git.ashish.kalra@amd.com> <88185cd3-a9f4-68a8-9c34-2e72deaf3d8d@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <88185cd3-a9f4-68a8-9c34-2e72deaf3d8d@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9580 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 mlxscore=0 adultscore=0 phishscore=0 bulkscore=0 suspectscore=5 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004030165 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9580 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 clxscore=1015 malwarescore=0 impostorscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 priorityscore=1501 lowpriorityscore=0 adultscore=0 suspectscore=5 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004030165 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-04-03 13:18:52 -0700, Krish Sadhukhan wrote: > > On 3/29/20 11:22 PM, Ashish Kalra wrote: > > From: Brijesh Singh > > > > The ioctl can be used to retrieve page encryption bitmap for a given > > gfn range. > > > > Return the correct bitmap as per the number of pages being requested > > by the user. Ensure that we only copy bmap->num_pages bytes in the > > userspace buffer, if bmap->num_pages is not byte aligned we read > > the trailing bits from the userspace and copy those bits as is. > > > > Cc: Thomas Gleixner > > Cc: Ingo Molnar > > Cc: "H. Peter Anvin" > > Cc: Paolo Bonzini > > Cc: "Radim Krčmář" > > Cc: Joerg Roedel > > Cc: Borislav Petkov > > Cc: Tom Lendacky > > Cc: x86@kernel.org > > Cc: kvm@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Brijesh Singh > > Signed-off-by: Ashish Kalra > > --- > > Documentation/virt/kvm/api.rst | 27 +++++++++++++ > > arch/x86/include/asm/kvm_host.h | 2 + > > arch/x86/kvm/svm.c | 71 +++++++++++++++++++++++++++++++++ > > arch/x86/kvm/x86.c | 12 ++++++ > > include/uapi/linux/kvm.h | 12 ++++++ > > 5 files changed, 124 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index ebd383fba939..8ad800ebb54f 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -4648,6 +4648,33 @@ This ioctl resets VCPU registers and control structures according to > > the clear cpu reset definition in the POP. However, the cpu is not put > > into ESA mode. This reset is a superset of the initial reset. > > +4.125 KVM_GET_PAGE_ENC_BITMAP (vm ioctl) > > +--------------------------------------- > > + > > +:Capability: basic > > +:Architectures: x86 > > +:Type: vm ioctl > > +:Parameters: struct kvm_page_enc_bitmap (in/out) > > +:Returns: 0 on success, -1 on error > > + > > +/* for KVM_GET_PAGE_ENC_BITMAP */ > > +struct kvm_page_enc_bitmap { > > + __u64 start_gfn; > > + __u64 num_pages; > > + union { > > + void __user *enc_bitmap; /* one bit per page */ > > + __u64 padding2; > > + }; > > +}; > > + > > +The encrypted VMs have concept of private and shared pages. The private > > +page is encrypted with the guest-specific key, while shared page may > > +be encrypted with the hypervisor key. The KVM_GET_PAGE_ENC_BITMAP can > > +be used to get the bitmap indicating whether the guest page is private > > +or shared. The bitmap can be used during the guest migration, if the page > > +is private then userspace need to use SEV migration commands to transmit > > +the page. > > + > > 5. The kvm_run structure > > ======================== > > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h > > index 90718fa3db47..27e43e3ec9d8 100644 > > --- a/arch/x86/include/asm/kvm_host.h > > +++ b/arch/x86/include/asm/kvm_host.h > > @@ -1269,6 +1269,8 @@ struct kvm_x86_ops { > > int (*enable_direct_tlbflush)(struct kvm_vcpu *vcpu); > > int (*page_enc_status_hc)(struct kvm *kvm, unsigned long gpa, > > unsigned long sz, unsigned long mode); > > + int (*get_page_enc_bitmap)(struct kvm *kvm, > > + struct kvm_page_enc_bitmap *bmap); > > > Looking back at the previous patch, it seems that these two are basically > the setter/getter action for page encryption, though one is implemented as a > hypercall while the other as an ioctl. If we consider the setter/getter > aspect, isn't it better to have some sort of symmetry in the naming of the > ops ? For example, > >         set_page_enc_hc > >         get_page_enc_ioctl > > > }; > > struct kvm_arch_async_pf { > > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > > index 1d8beaf1bceb..bae783cd396a 100644 > > --- a/arch/x86/kvm/svm.c > > +++ b/arch/x86/kvm/svm.c > > @@ -7686,6 +7686,76 @@ static int svm_page_enc_status_hc(struct kvm *kvm, unsigned long gpa, > > return ret; > > } > > +static int svm_get_page_enc_bitmap(struct kvm *kvm, > > + struct kvm_page_enc_bitmap *bmap) > > +{ > > + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > > + unsigned long gfn_start, gfn_end; > > + unsigned long sz, i, sz_bytes; > > + unsigned long *bitmap; > > + int ret, n; > > + > > + if (!sev_guest(kvm)) > > + return -ENOTTY; > > + > > + gfn_start = bmap->start_gfn; > > > What if bmap->start_gfn is junk ? > > > + gfn_end = gfn_start + bmap->num_pages; > > + > > + sz = ALIGN(bmap->num_pages, BITS_PER_LONG) / BITS_PER_BYTE; > > + bitmap = kmalloc(sz, GFP_KERNEL); > > + if (!bitmap) > > + return -ENOMEM; > > + > > + /* by default all pages are marked encrypted */ > > + memset(bitmap, 0xff, sz); > > + > > + mutex_lock(&kvm->lock); > > + if (sev->page_enc_bmap) { > > + i = gfn_start; > > + for_each_clear_bit_from(i, sev->page_enc_bmap, > > + min(sev->page_enc_bmap_size, gfn_end)) > > + clear_bit(i - gfn_start, bitmap); > > + } > > + mutex_unlock(&kvm->lock); > > + > > + ret = -EFAULT; > > + > > + n = bmap->num_pages % BITS_PER_BYTE; > > + sz_bytes = ALIGN(bmap->num_pages, BITS_PER_BYTE) / BITS_PER_BYTE; > > + > > + /* > > + * Return the correct bitmap as per the number of pages being > > + * requested by the user. Ensure that we only copy bmap->num_pages > > + * bytes in the userspace buffer, if bmap->num_pages is not byte > > + * aligned we read the trailing bits from the userspace and copy > > + * those bits as is. > > + */ > > + > > + if (n) { > > > Is it better to check for 'num_pages' at the beginning of the function > rather than coming this far if bmap->num_pages is zero ? > > > + unsigned char *bitmap_kernel = (unsigned char *)bitmap; > > > Just trying to understand why you need this extra variable instead of using > 'bitmap' directly. > > > + unsigned char bitmap_user; > > + unsigned long offset, mask; > > + > > + offset = bmap->num_pages / BITS_PER_BYTE; > > + if (copy_from_user(&bitmap_user, bmap->enc_bitmap + offset, > > + sizeof(unsigned char))) > > + goto out; > > + > > + mask = GENMASK(n - 1, 0); > > + bitmap_user &= ~mask; > > + bitmap_kernel[offset] &= mask; > > + bitmap_kernel[offset] |= bitmap_user; > > + } > > + > > + if (copy_to_user(bmap->enc_bitmap, bitmap, sz_bytes)) > > > If 'n' is zero, we are still copying stuff back to the user. Is that what is > expected from userland ? > > Another point. Since copy_from_user() was done in the caller, isn't it > better to move this to the caller to keep a symmetry ? That would need the interface of .get_page_enc_bitmap to change, to pass back the local bitmap to the caller for use in copy_to_user() and then free it up. I think it is better to call copy_to_user() here and free the bitmap before returning. > > > + goto out; > > + > > + ret = 0; > > +out: > > + kfree(bitmap); > > + return ret; > > +} > > + > > static int svm_mem_enc_op(struct kvm *kvm, void __user *argp) > > { > > struct kvm_sev_cmd sev_cmd; > > @@ -8090,6 +8160,7 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = { > > .apic_init_signal_blocked = svm_apic_init_signal_blocked, > > .page_enc_status_hc = svm_page_enc_status_hc, > > + .get_page_enc_bitmap = svm_get_page_enc_bitmap, > > }; > > static int __init svm_init(void) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > index 68428eef2dde..3c3fea4e20b5 100644 > > --- a/arch/x86/kvm/x86.c > > +++ b/arch/x86/kvm/x86.c > > @@ -5226,6 +5226,18 @@ long kvm_arch_vm_ioctl(struct file *filp, > > case KVM_SET_PMU_EVENT_FILTER: > > r = kvm_vm_ioctl_set_pmu_event_filter(kvm, argp); > > break; > > + case KVM_GET_PAGE_ENC_BITMAP: { > > + struct kvm_page_enc_bitmap bitmap; > > + > > + r = -EFAULT; > > + if (copy_from_user(&bitmap, argp, sizeof(bitmap))) > > + goto out; > > + > > + r = -ENOTTY; > > + if (kvm_x86_ops->get_page_enc_bitmap) > > + r = kvm_x86_ops->get_page_enc_bitmap(kvm, &bitmap); > > + break; > > + } > > default: > > r = -ENOTTY; > > } > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > > index 4e80c57a3182..db1ebf85e177 100644 > > --- a/include/uapi/linux/kvm.h > > +++ b/include/uapi/linux/kvm.h > > @@ -500,6 +500,16 @@ struct kvm_dirty_log { > > }; > > }; > > +/* for KVM_GET_PAGE_ENC_BITMAP */ > > +struct kvm_page_enc_bitmap { > > + __u64 start_gfn; > > + __u64 num_pages; > > + union { > > + void __user *enc_bitmap; /* one bit per page */ > > + __u64 padding2; > > + }; > > +}; > > + > > /* for KVM_CLEAR_DIRTY_LOG */ > > struct kvm_clear_dirty_log { > > __u32 slot; > > @@ -1478,6 +1488,8 @@ struct kvm_enc_region { > > #define KVM_S390_NORMAL_RESET _IO(KVMIO, 0xc3) > > #define KVM_S390_CLEAR_RESET _IO(KVMIO, 0xc4) > > +#define KVM_GET_PAGE_ENC_BITMAP _IOW(KVMIO, 0xc5, struct kvm_page_enc_bitmap) > > + > > /* Secure Encrypted Virtualization command */ > > enum sev_cmd_id { > > /* Guest initialization commands */