Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp6702037ybl; Wed, 15 Jan 2020 08:51:44 -0800 (PST) X-Google-Smtp-Source: APXvYqxKmHpOvkpHl/ij4I9t7a2Nh5svoTqjFpKa0VA/EXYS6K7ZLo51mVcbJD5dxavjGbez7FRL X-Received: by 2002:aca:c5ca:: with SMTP id v193mr565700oif.77.1579107104222; Wed, 15 Jan 2020 08:51:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579107104; cv=none; d=google.com; s=arc-20160816; b=xUnhazRxfsb7mBkgQ05KVGlAZE36QSrmEDUabDvjZKqYYXl7F7JzIhZI7FUqzcpe03 tSWjvAyxQjlbp0paL6YUyX5lV5g4lDPI1hoaDAcnuoK/O/9g+rbhaIUH1ftLFgdcLktX p4ieSMnJc1A3sJXFEgJeSFmlcfDHfQpeMNxRe9kbkvUIhEbBURSuJV1jwT0IRiuBMUvL WI0YFQw3RPHn7nt3BF3ix0MvCSGFZQAgbDkSshxRJmofe+JPfhUvSyuE+0XhGVcJnxQg NuQgNoBHdiDbc5Y/OmUWUVSsDXSoNbsS/2U1B7x0ErkUNLKWVY5OLDCEBOkCj8Achcci c/VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=VfoUnG2aUMrp0ODubFwJ9CqBpCcuIJ4gL3/SrqOoXF8=; b=CfDxMlC8jEiaK7Irk8kWHNmLE/93Vs/stNQ1AoWs+y7eZpsWb3Ca11vX4HaR3LUPl2 /baa28QHUyGw1gzQ2Hi5jeCbhlMa6ykeXzUb+m2vpQ1AmsxKXjk0qNwRcAc5NcrcTTLu dzsV3E1DT2gBxhuXpmAaM3unGnznxyvwnTOD57dxL7RnPpJeF522vyB7MsgMH1JV4L7P Pj5vxjhwBUL181LC5r9HKuBLu5rAt/5sR/9GEIvYT62k0M35jUkw6G0BWbC+c1HigivY 8W6ACPP5JggjO8quR/8SCd6kED5zZ7uADRAymjc3aKPHR1Ac7cbnswE7dbPfv5v6efD0 r2YQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UffcExkX; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a128si9439739oib.142.2020.01.15.08.51.31; Wed, 15 Jan 2020 08:51:44 -0800 (PST) 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=@redhat.com header.s=mimecast20190719 header.b=UffcExkX; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728927AbgAOQu3 (ORCPT + 99 others); Wed, 15 Jan 2020 11:50:29 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:36909 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726574AbgAOQu2 (ORCPT ); Wed, 15 Jan 2020 11:50:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579107027; 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=VfoUnG2aUMrp0ODubFwJ9CqBpCcuIJ4gL3/SrqOoXF8=; b=UffcExkXGrkvbSk4bZgmfz3UBZsyIIJfN7si7QaV+b+WvFvanqvYGWMV0wAcV2/Ilcf6SF rdZZrp36KVs68Fi0q6jVdngOISn/+EQihgqZT/1gd4zlnGuIGAjtNOegW+02VASNhvRy/q +YBVxlR9Lo/qlJAEE88QgV31gl6qoqU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-100-j9uCFyAdPkalB9qb-hno5w-1; Wed, 15 Jan 2020 11:50:24 -0500 X-MC-Unique: j9uCFyAdPkalB9qb-hno5w-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3DE95DB20; Wed, 15 Jan 2020 16:50:23 +0000 (UTC) Received: from asgard.redhat.com (ovpn-112-36.ams2.redhat.com [10.36.112.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8ED3E6609E; Wed, 15 Jan 2020 16:50:20 +0000 (UTC) Date: Wed, 15 Jan 2020 17:50:17 +0100 From: Eugene Syromiatnikov To: Jens Axboe Cc: linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org, Alexander Viro , linux-kernel@vger.kernel.org, Jeff Moyer , "Dmitry V. Levin" Subject: Re: [PATCH] io_uring: fix compat for IORING_REGISTER_FILES_UPDATE Message-ID: <20200115165017.GI1333@asgard.redhat.com> References: <20200115163538.GA13732@asgard.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 15, 2020 at 09:41:58AM -0700, Jens Axboe wrote: > On 1/15/20 9:35 AM, Eugene Syromiatnikov wrote: > > fds field of struct io_uring_files_update is problematic with regards > > to compat user space, as pointer size is different in 32-bit, 32-on-64-bit, > > and 64-bit user space. In order to avoid custom handling of compat in > > the syscall implementation, make fds __u64 and use u64_to_user_ptr in > > order to retrieve it. Also, align the field naturally and check that > > no garbage is passed there. > > Good point, it's an s32 pointer so won't align nicely. But how about > just having it be: > > struct io_uring_files_update { > __u32 offset; > __u32 resv; > __s32 *fds; > }; > > which should align nicely on both 32 and 64-bit? The issue is that 32-bit user space would pass a 12-byte structure with a 4-byte pointer in it to the 64-bit kernel, that, in turn, would treat it as a 8-byte value (which might sometimes work on little-endian architectures, if there are happen to be zeroes after the pointer, but will be always broken on big-endian ones). __u64 is used in order to avoid special compat wrapper; see, for example, __u64 usage in btrfs or BPF for similar purposes. > -- > Jens Axboe >