Received: by 2002:a05:6358:51dd:b0:131:369:b2a3 with SMTP id 29csp366048rwl; Wed, 9 Aug 2023 16:08:46 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH9RMBkPuAnAbq9RX00FWuZlmXLH6p6xhXvwpAgj5PtDiIt1INVHk5ZNkKkAv2uodkyZDcB X-Received: by 2002:a17:903:110d:b0:1b8:94f4:3e0 with SMTP id n13-20020a170903110d00b001b894f403e0mr604363plh.14.1691622525952; Wed, 09 Aug 2023 16:08:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691622525; cv=none; d=google.com; s=arc-20160816; b=D46879HrhFMn+A5Ko3RbBURSsvXw41XaYUP2UMgffOeFe3yyiQCyJPxIQfWfYdycA7 srA8BW+QZbIVaad+Y31FUliXRjN0sjo4j+DgLcBFcvxPMF7orXYVTkFKc/GyRhPVOBsB ovGNysLRJtPEG+5Zipk3GEybOgPk717ZIc0pvtOaPycym29/CSzKtHQjrNuDz61NhXBg QEOJYOD6syg1WJChdhuJTe4WwD777aoTIgOAS7sskJlXc/VNZmolzzSk+4S2Kj+IdMks j0WGAaJD0COchnjeZ5UfGh5DxSy3wksDDHGl74uAw+LL6CCVUTzQ8b2h+1mkbANYNYkI wPug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=9pYnh9AZiLo/QufdQ00bPfQxtHLj4posydlYcWhbRmM=; fh=Jwapm4lq68h1feOUtcYIIIrxRv5RQSItvJsoua3O5Rw=; b=WTlM+NJRH8yds9j9BSpFfUuh5/bVd8UbluPOsdBe6v2EOj7JpGPkwHfeNXS3xZaSma uAgpZouJvcs9T7Mqx7h7SEfYADlnn3LGVdZ0kG8X8hlM7EKhlh31rdLyLWM5Qaf32/E4 tcpW2GjfmKpIiF2C86nCyWvtY/+6O34yKKpYs2ZjsSdLBgUX2H8TTOKGTy17tsawXWCp aesmIaB4jN9QnGfG6+Ka9bbTZOjArdpgavHPGmrpVGWqLMn5G8YrZfh+EOhSxKjZkHnk aPTdMURn4Ho4tc1xGHZXEnwWUQyhiJA1uXKXFghZpHVzXlXjLSnwLlDyfOsxT5iKT0cJ /f8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IX6p8bq5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id lg8-20020a170902fb8800b001b86671b3f1si142243plb.190.2023.08.09.16.08.31; Wed, 09 Aug 2023 16:08:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=IX6p8bq5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232364AbjHIVE4 (ORCPT + 99 others); Wed, 9 Aug 2023 17:04:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229934AbjHIVEx (ORCPT ); Wed, 9 Aug 2023 17:04:53 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8C7741BFB for ; Wed, 9 Aug 2023 14:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691615026; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9pYnh9AZiLo/QufdQ00bPfQxtHLj4posydlYcWhbRmM=; b=IX6p8bq50UKFX0lPwt5fbg+tGPOfgGQbK8MFirGGdJkRlzseRvba0b8WUK8PItSc3ELtUt vAIh/xLmwEAd2H3FjNCoflF1Ve46j9CqKgE47D6t41GEVnCwmaeuJ9Xw0cVzycFSETeM6a s/+4n1BSNExInVL7nq6RfCtChz+o1Bk= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-146-vVAOG69QMN2a86L0HEy8cg-1; Wed, 09 Aug 2023 17:03:43 -0400 X-MC-Unique: vVAOG69QMN2a86L0HEy8cg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BA971380673C; Wed, 9 Aug 2023 21:03:41 +0000 (UTC) Received: from localhost (unknown [10.39.192.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id 20376C15BAE; Wed, 9 Aug 2023 21:03:40 +0000 (UTC) From: Stefan Hajnoczi To: kvm@vger.kernel.org Cc: Jason Gunthorpe , "Tian, Kevin" , linux-kernel@vger.kernel.org, Alex Williamson , Stefan Hajnoczi Subject: [PATCH 4/4] vfio: use __aligned_u64 in struct vfio_device_ioeventfd Date: Wed, 9 Aug 2023 17:02:48 -0400 Message-ID: <20230809210248.2898981-5-stefanha@redhat.com> In-Reply-To: <20230809210248.2898981-1-stefanha@redhat.com> References: <20230809210248.2898981-1-stefanha@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The memory layout of struct vfio_device_ioeventfd is architecture-dependent due to a u64 field and a struct size that is not a multiple of 8 bytes: - On x86_64 the struct size is padded to a multiple of 8 bytes. - On x32 the struct size is only a multiple of 4 bytes, not 8. - Other architectures may vary. Use __aligned_u64 to make memory layout consistent. This reduces the chance of holes that result in an information leak and the chance that 32-bit userspace on a 64-bit kernel breakage. This patch increases the struct size on x32 but this is safe because of the struct's argsz field. The kernel may grow the struct as long as it still supports smaller argsz values from userspace (e.g. applications compiled against older kernel headers). The code that uses struct vfio_device_ioeventfd already works correctly when the struct size grows, so only the struct definition needs to be changed. Suggested-by: Jason Gunthorpe Signed-off-by: Stefan Hajnoczi --- include/uapi/linux/vfio.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h index 0b5786ec50d8..d61269765bf8 100644 --- a/include/uapi/linux/vfio.h +++ b/include/uapi/linux/vfio.h @@ -794,9 +794,10 @@ struct vfio_device_ioeventfd { #define VFIO_DEVICE_IOEVENTFD_32 (1 << 2) /* 4-byte write */ #define VFIO_DEVICE_IOEVENTFD_64 (1 << 3) /* 8-byte write */ #define VFIO_DEVICE_IOEVENTFD_SIZE_MASK (0xf) - __u64 offset; /* device fd offset of write */ - __u64 data; /* data to be written */ + __aligned_u64 offset; /* device fd offset of write */ + __aligned_u64 data; /* data to be written */ __s32 fd; /* -1 for de-assignment */ + __u32 reserved; }; #define VFIO_DEVICE_IOEVENTFD _IO(VFIO_TYPE, VFIO_BASE + 16) -- 2.41.0