From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08754C04A6A for ; Thu, 10 Aug 2023 14:25:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235597AbjHJOZX (ORCPT ); Thu, 10 Aug 2023 10:25:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47262 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232018AbjHJOZP (ORCPT ); Thu, 10 Aug 2023 10:25:15 -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 D198B125 for ; Thu, 10 Aug 2023 07:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1691677467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EGOPK6ESp6BA2jZeEYrFpzQG3cNbtY0GBXHT9EG8kSQ=; b=LcXxM1o9w9iKsajOJzvxxeBaLLm937/t6GD/m+Ho74RwHpGnvSsz3GiV6t4NdRFkd1JeKk JtBwt+6jjapwNawviekLfIfTZiGYoaLfD6l0cApOqCD3suIF8itVl1mc/nOaIR2vJFKOuM V54Mi8kpgJWOHVWctEonOqc37UDA51o= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-198-Mdk96T5RNxGim5e_Far3KA-1; Thu, 10 Aug 2023 10:24:23 -0400 X-MC-Unique: Mdk96T5RNxGim5e_Far3KA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0191A85C70F; Thu, 10 Aug 2023 14:24:23 +0000 (UTC) Received: from localhost (unknown [10.39.194.92]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7D044401E63; Thu, 10 Aug 2023 14:24:22 +0000 (UTC) Date: Thu, 10 Aug 2023 10:24:20 -0400 From: Stefan Hajnoczi To: "Tian, Kevin" Cc: "kvm@vger.kernel.org" , Jason Gunthorpe , "linux-kernel@vger.kernel.org" , Alex Williamson Subject: Re: [PATCH 2/4] vfio: use __aligned_u64 in struct vfio_device_gfx_plane_info Message-ID: <20230810142420.GC2931656@fedora> References: <20230809210248.2898981-1-stefanha@redhat.com> <20230809210248.2898981-3-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O6bfz7OyLmHoLzjF" Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --O6bfz7OyLmHoLzjF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 10, 2023 at 03:22:56AM +0000, Tian, Kevin wrote: > > From: Stefan Hajnoczi > > Sent: Thursday, August 10, 2023 5:03 AM > >=20 > > The memory layout of struct vfio_device_gfx_plane_info 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. > >=20 > > Use __aligned_u64 to make memory layout consistent. This reduces the > > chance of holes that result in an information leak and the chance that >=20 > I didn't quite get this. The leak example [1] from your earlier fix is re= ally > not caused by the use of __u64. Instead it's a counter example that on > x32 there is no hole with 4byte alignment for __u64. >=20 > I'd remove the hole part and just keep the compat reason. >=20 > [1] https://lore.kernel.org/lkml/20230801103114.757d7992.alex.williamson@= redhat.com/T/ Okay. >=20 > > @@ -1392,6 +1392,8 @@ static long intel_vgpu_ioctl(struct vfio_device > > *vfio_dev, unsigned int cmd, > > if (dmabuf.argsz < minsz) > > return -EINVAL; > >=20 > > + minsz =3D min(minsz, sizeof(dmabuf)); > > + >=20 > Is there a case where minsz could be greater than sizeof(dmabuf)? Thanks for spotting this, it's a bug in the patch. It should be min(dmabuf.argsz, sizeof(dmabuf)). Stefan --O6bfz7OyLmHoLzjF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmTU8xQACgkQnKSrs4Gr c8jKDgf/RLZgbtwtI72CjE2KiK0+kuRGCyKg6g5IlhEVfIhGpdr+MMHc4q2uUi6b 2pXvDCegcThH0hDv66q2HW9pGdv6CKSTuUuCv0TpKqocxTMImMTWPxBIsN7oslpJ oOxe3PPzC2jtFQyZkwmsP2yjekvq0e6tPOmaYJMFflBnR1o3SncsLP/Z3TyInMQr Sron45lvEXLQAH/xHjguvNzACgVLZiJB0/weTWJqi03KEqFw2/YSxX85M1yRLYhp e/Lfk7FSBAYoNKUXm6pJM/ULEKTbxkH4zb1JwejCkzJ4PPYXsl/MLZZhXnNFPvJ0 /oDPG/KSh9YMo6iS2wQ2Fl8yN50BBQ== =ESeR -----END PGP SIGNATURE----- --O6bfz7OyLmHoLzjF--