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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 548D3C388F7 for ; Thu, 22 Oct 2020 20:07:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD6FE24182 for ; Thu, 22 Oct 2020 20:07:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD6FE24182 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2B4126B005D; Thu, 22 Oct 2020 16:07:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 289036B006E; Thu, 22 Oct 2020 16:07:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A2F16B0070; Thu, 22 Oct 2020 16:07:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0028.hostedemail.com [216.40.44.28]) by kanga.kvack.org (Postfix) with ESMTP id E1EAF6B005D for ; Thu, 22 Oct 2020 16:07:11 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 86286180AD815 for ; Thu, 22 Oct 2020 20:07:11 +0000 (UTC) X-FDA: 77400645462.28.rifle53_541869e27253 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id 5D2E46C05; Thu, 22 Oct 2020 20:07:11 +0000 (UTC) X-HE-Tag: rifle53_541869e27253 X-Filterd-Recvd-Size: 7302 Received: from mout-xforward.kundenserver.de (mout-xforward.kundenserver.de [82.165.159.43]) by imf02.hostedemail.com (Postfix) with ESMTP; Thu, 22 Oct 2020 20:07:10 +0000 (UTC) Received: from mail-qt1-f181.google.com ([209.85.160.181]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MMFZQ-1korbp1Wz8-00JH1J; Thu, 22 Oct 2020 22:07:07 +0200 Received: by mail-qt1-f181.google.com with SMTP id h19so2269382qtq.4; Thu, 22 Oct 2020 13:07:06 -0700 (PDT) X-Gm-Message-State: AOAM533CewDCNanDdu0zftZkr8bHKC3xY6krjrXKnxugneUOQ3B95vwJ dt7Cvh9TqXvDMHDyMiKjVSzj6MJ7dErDpCiqTVE= X-Google-Smtp-Source: ABdhPJwzGzK/joUQSVeAvrqX5qVjZKbTZlqR4y2OtmQidVm+hBPHFgPJ0w6zcUfZJ+QK7ijfxiYnDR24hCknqBCxhWQ= X-Received: by 2002:ac8:7cba:: with SMTP id z26mr3769485qtv.7.1603397225784; Thu, 22 Oct 2020 13:07:05 -0700 (PDT) MIME-Version: 1.0 References: <20201021233914.GR3576660@ZenIV.linux.org.uk> <20201022082654.GA1477657@kroah.com> <80a2e5fa-718a-8433-1ab0-dd5b3e3b5416@redhat.com> <5d2ecb24db1e415b8ff88261435386ec@AcuMS.aculab.com> <20201022090155.GA1483166@kroah.com> <5fd6003b-55a6-2c3c-9a28-8fd3a575ca78@redhat.com> <20201022132342.GB8781@lst.de> <8f1fff0c358b4b669d51cc80098dbba1@AcuMS.aculab.com> In-Reply-To: From: Arnd Bergmann Date: Thu, 22 Oct 2020 22:06:49 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c" To: Nick Desaulniers Cc: David Laight , Christoph Hellwig , David Hildenbrand , Greg KH , Al Viro , "kernel-team@android.com" , Andrew Morton , Jens Axboe , David Howells , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-s390@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-aio@kvack.org" , "io-uring@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-mm@kvack.org" , "netdev@vger.kernel.org" , "keyrings@vger.kernel.org" , "linux-security-module@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:S6N1fqCB7NFhD/lsYlClGxbRsxZ0Z1j31z+eiSpg2lr3keLWlq1 wiv0/h0MP000bnSm17oMvaPlB1p4c6k8iYCt9t+nX5AcveHnXdD7uMvM2ggWJ0Bse9TcQaW Uejdfb5E+r2F3++XtOxr3ptPGtVBHdJ+s6uMt6+VkXfmLUC4hZ9UCS795RN+roCSXJWcdVw lgthaORwUNtsY8ZGDR2Qw== X-UI-Out-Filterresults: junk:10;V03:K0:9QYRzHCQ/6Y=:fIefE4jHXWilRCu9u5mqTHkN oj2C+FdPO9qkb2rGkv/Mqh5bPBkWIshnLn+VgEYwfCa6GrSp1ZxKNaIQCAi+gB+29vs42jvk3 Yu1ORleJdaVlxPOtTqB5YiWKb+jkVnyRqlq65mjtWAKX5PWpf7mqVWXMvSb9z1oCMI+Aix+Pv myahtA4USLLGrspVkGzmbSOMIN9Qks9R3YoKrW+H3Q4BY0bjAAs98k7KAvqTJTjiKrXXwkwl8 zw/QC2tO3LbnLhiXA6c02TTAfqCnRXjDvibnTg8+YiXKy5r2MzM5ebdd0xuolfHmjEhdcTTGl WgioTbugxwTb3UvdDZs68sv/eJBExO7421dGb1ZldqmDrRQgQni0chw4X9Ltf2iiOAIn1Kgc4 uJ0LVygGGaTD7tdUKeYLQkZFElWRXBQL3NPln5cJ4jutiHeupB/tcuk7fFeLVsj6NFHFdsw0G HdMDNXxeevdo6Z/Mbag7p+/3NMB0bNet3JLB2i0iDUEvr3YUykdeSRzGVBFbo2g04JDzonRF/ PVcSsdBit/XnHwDGZ7PtD8bYKfowaK0gjxr9Js78S5Rppx1DVVK6rz/+7Z9JSpFzmRUpmFhhR cR3AOYpHUDyrIjhoJ4jiybQbL1zwyBJ7WL94Q2/tspxM0TPbSWwQlg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 22, 2020 at 9:05 PM Nick Desaulniers wrote: > > On Thu, Oct 22, 2020 at 11:13 AM Arnd Bergmann wrote: > > > > On Thu, Oct 22, 2020 at 7:54 PM Nick Desaulniers > > wrote: > > > On Thu, Oct 22, 2020 at 9:35 AM David Laight wrote: > > > > > > > > Which makes it a bug in the kernel C syscall wrappers. > > > > They need to explicitly mask the high bits of 32bit > > > > arguments on arm64 but not x86-64. > > > > > > Why not x86-64? Wouldn't it be *any* LP64 ISA? > > > > x86-64 is slightly special because most instructions on a 32-bit > > argument clear the upper 32 bits, while on most architectures > > the same instruction would leave the upper bits unchanged. > > Oh interesting, depends on the operations too on x86_64 IIUC? It seems this doesn't impact the calling conventions (see below), it's just that there are more cases on x86 where the callee doesn't have to explicitly clear the upper bits because the this is implied. > > > Attaching a patch that uses the proper width, but I'm pretty sure > > > there's still a signedness issue . Greg, would you mind running this > > > through the wringer? > > > > I would not expect this to change anything for the bug that Greg > > is chasing, unless there is also a bug in clang. > > > > In the version before the patch, we get a 64-bit argument from > > user space, which may consist of the intended value in the lower > > bits plus garbage in the upper bits. However, vlen only gets > > passed down into import_iovec() without any other operations > > on it, and since import_iovec takes a 32-bit argument, this is > > where it finally gets narrowed. > > Passing an `unsigned long` as an `unsigned int` does no such > narrowing: https://godbolt.org/z/TvfMxe (same vice-versa, just tail > calls, no masking instructions). Sorry I got it wrong, looked up the aarch64 AAPCS now, which explains "Unlike in the 32-bit AAPCS, named integral values must be narrowed by the callee rather than the caller." Also confirmed using https://godbolt.org/z/acPrjj, which shows more combinations of compilers and architectures in addition to your example. I had expected arm64 to be like powerpc64 and arm32 in this case, but it's the reverse. I also verified that SYSCALL_DEFINEx() is correct on arm64 and saw that as of v4.19 it passes the syscall arguments through pt_regs, which will do the right thing here regardless of the argument passing rules. The earlier version also seems to be working as intended. Arnd