Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3940082imm; Mon, 8 Oct 2018 12:02:09 -0700 (PDT) X-Google-Smtp-Source: ACcGV62rgPrnGQ7WmaN6ZPbjmxM8ZNu3gBB4i1898ilh1gBP7ZlTZkOiUcWSs0KvbeQGoafzfLfn X-Received: by 2002:a17:902:421:: with SMTP id 30-v6mr19256270ple.184.1539025329936; Mon, 08 Oct 2018 12:02:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539025329; cv=none; d=google.com; s=arc-20160816; b=RiAdCg44OvIkXg5T1bly/4X+dsaxA7/1Pj7aywIKioiu8zm6YRmSX1yBKihgJJa7Yt Hhnd9peX22mXY9rf9LY82K/Rk3LbeonNCh6iJ6lVnDfN3EdDMrN7zUsnad8ln1yeem2h xPXP/4SZrshk/m1fTvkel04YwpMorrGDs+8BEu7wYaQIFIntKzEHZJBr0lGPoHnHvJ7t HaSsDjrMxiKBqbMhBH+dRKL+xldUKILWSbdOFENZf2Kq0pN3Wu/bjvdrNmfX02/+abcj beZJpuug/F2SiXkc+L3uDSrkbP+Tl5kAn7C7nGHHvHZyuHlsb+KrxRoSx3Buu2IX7Lc9 lj4Q== 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=AqVqcCk0317Ev+zmuDA5P8h8eAILWr/22L8x8CdqSUU=; b=PlKv1Q6/nCDG+qy0Viu846lUcNwjfcDsbcyTLSDsDDLOG/OMjoP5E5je8EvkDTBm4c MUY/RbeWvU7TCDke/ywYguv5gZ/dPf59dmA4AinThb67QYRFJl3BFa023ySjABqtmP7r F4yMkGhZHbkId0cRZJWAdSK75ayunOHQSTfaiNtRgI+KoZbLAbTwactC90yZQgStYQh7 T8O4nXGNottpCQf9uky3f8ZijX72HxgumFlSPqPQgsIL5nv3PHddCcG8suczyR6mta3o RGfcMVaG3HllNAQvipsMfJGRitz4kEYpK0i8I6X6UFrMg7lNsyW8v/UyRB6B/W91CTuw dMyw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a8-v6si18991487ple.80.2018.10.08.12.01.54; Mon, 08 Oct 2018 12:02:09 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731489AbeJICAq (ORCPT + 99 others); Mon, 8 Oct 2018 22:00:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39030 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730798AbeJICAq (ORCPT ); Mon, 8 Oct 2018 22:00:46 -0400 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5932C034DF4; Mon, 8 Oct 2018 18:47:39 +0000 (UTC) Received: from w520.home (ovpn-116-90.phx2.redhat.com [10.3.116.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id 353575D784; Mon, 8 Oct 2018 18:47:38 +0000 (UTC) Date: Mon, 8 Oct 2018 12:47:38 -0600 From: Alex Williamson To: Wenwen Wang Cc: Kangjie Lu , kvm@vger.kernel.org (open list:VFIO DRIVER), linux-kernel@vger.kernel.org (open list), Subject: Re: [PATCH v2] drivers/vfio: Fix a redundant copy bug Message-ID: <20181008124738.23a547d0@w520.home> In-Reply-To: <1539021980-2412-1-git-send-email-wang6495@umn.edu> References: <1539021980-2412-1-git-send-email-wang6495@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 08 Oct 2018 18:47:40 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Oct 2018 13:06:20 -0500 Wenwen Wang wrote: > In vfio_spapr_iommu_eeh_ioctl(), if the ioctl command is VFIO_EEH_PE_OP, > the user-space buffer 'arg' is copied to the kernel object 'op' and the > 'argsz' and 'flags' fields of 'op' are checked. If the check fails, an > error code EINVAL is returned. Otherwise, 'op.op' is further checked > through a switch statement to invoke related handlers. If 'op.op' is > VFIO_EEH_PE_INJECT_ERR, the whole user-space buffer 'arg' is copied again > to 'op' to obtain the err information. However, in the following execution > of this case, the fields of 'op', except the field 'err', are actually not > used. That is, the second copy has a redundant part. Therefore, for both > performance consideration, the redundant part of the second copy should be > removed. > > This patch removes such a part in the second copy. It only copies from > 'err.type' to 'err.mask', which is exactly required by the > VFIO_EEH_PE_INJECT_ERR op. > > Signed-off-by: Wenwen Wang > --- > drivers/vfio/vfio_spapr_eeh.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/vfio/vfio_spapr_eeh.c b/drivers/vfio/vfio_spapr_eeh.c > index 38edeb4..66634c6 100644 > --- a/drivers/vfio/vfio_spapr_eeh.c > +++ b/drivers/vfio/vfio_spapr_eeh.c > @@ -37,6 +37,7 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group, > struct eeh_pe *pe; > struct vfio_eeh_pe_op op; > unsigned long minsz; > + unsigned long start, end; > long ret = -EINVAL; > > switch (cmd) { > @@ -86,10 +87,12 @@ long vfio_spapr_iommu_eeh_ioctl(struct iommu_group *group, > ret = eeh_pe_configure(pe); > break; > case VFIO_EEH_PE_INJECT_ERR: > - minsz = offsetofend(struct vfio_eeh_pe_op, err.mask); > - if (op.argsz < minsz) > + start = offsetof(struct vfio_eeh_pe_op, err.type); We already have this in minsz, offsetofend(,op) == offsetof(,err.type). That can't change without breaking userspace. > + end = offsetofend(struct vfio_eeh_pe_op, err.mask); > + if (op.argsz < end) > return -EINVAL; > - if (copy_from_user(&op, (void __user *)arg, minsz)) > + if (copy_from_user(&op.err, (char __user *)arg + > + start, end - start)) So we trade 12 bytes of redundant copy for an extra stack variable and an arithmetic operation, not necessarily an obvious win, but more correct I guess. Alexey, I also notice that these 12 bytes means that the u64 fields in struct vfio_eeh_pe_err are not 8-byte aligned which could lead to compiler dependent packing interpretation issues with userspace. Should there be a 4-byte reserved field in there to make it explicit (so long as it matches the current interpretation)? Thanks, Alex