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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 17796C433B4 for ; Tue, 18 May 2021 07:45:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F346961353 for ; Tue, 18 May 2021 07:45:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347267AbhERHrC (ORCPT ); Tue, 18 May 2021 03:47:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:36974 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347262AbhERHqz (ORCPT ); Tue, 18 May 2021 03:46:55 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 0401261354; Tue, 18 May 2021 07:45:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621323932; bh=Y+V2srtgNnzj+sz2D9W3MzRLHA3Oyb4L5KvaOMTQZcU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vK5VwonkDkZYGOJp6YPxhRKo6knrgsSkaAV/BX3HDLzqeEaTAA+6V1aM0uWRDthgO GA7xKHvqnbCcxPWVCRWRH2Taf9+f9jqeDMaFKjz1LKAzQsp9D0Hj6SKDK7AgkY9npN sg8FN/TpGhAqh4JO7a2DPGtzS2OTYOEWJSQhvhiGqNSA3PDbQL21zcnKcro361OA2B IBdhXiQuiIN9AqsY8tKloo056FxIXo4X+X7QWU4SkRt/RDz64TQOfPaQL97O5SNST4 pFYGuFPVxLVdQbqr6YF2uL28MgO9SvebKPyOiEI8oWODxf2w2ZWKAf0o1A9GfGxwqA TyrtMikqL9vqQ== Received: by mail-wr1-f54.google.com with SMTP id z17so9025539wrq.7; Tue, 18 May 2021 00:45:31 -0700 (PDT) X-Gm-Message-State: AOAM532pYNhbYCwIOE0jH2gDbkHp51VeR1kuO38iOQE7Ole+hOZYORDt ztX3+qmg43Hb6txnWxnSZ3ni+r0g9qv0ofnKmuQ= X-Google-Smtp-Source: ABdhPJzB9aNOakOhJJsNXyx8q3Jo6fxvkR8RjdO1U05M07un4qbYlL3TFt5Q+CmgOiR5uSU3DTozp5J+ZhaPeYV8A5U= X-Received: by 2002:a5d:5404:: with SMTP id g4mr5184734wrv.286.1621323930626; Tue, 18 May 2021 00:45:30 -0700 (PDT) MIME-Version: 1.0 References: <20210517203343.3941777-1-arnd@kernel.org> <20210517203343.3941777-2-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Tue, 18 May 2021 09:44:20 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/4] kexec: simplify compat_sys_kexec_load To: Christoph Hellwig Cc: "Eric W. Biederman" , linux-arch , Alexander Viro , Andrew Morton , Borislav Petkov , Brian Gerst , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Linux ARM , Linux Kernel Mailing List , Linux-MM , kexec@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 18, 2021 at 8:40 AM Christoph Hellwig wrote: > > On Mon, May 17, 2021 at 10:57:24PM -0500, Eric W. Biederman wrote: > > We open ourselves up to bugs whenever we lie to the type system. > > > > Skimming through the code it looks like it should be possible > > to not need the in_compat_syscall and the casts to the wrong > > type by changing the order of the code a little bit. There are obviously other ways of doing the same. The reason for doing it this specific way is so I can eliminate the compat entry point entirely in patch 4/4. > What kind of bug do you expect? We must only copy from user addresses > once anyway. I've never seen bugs due the use of in_compat_syscall, > but plenty due to cruft code trying to avoid it. Right, I've used the same approach of passing a native-typed __user pointer and converting it in a copy_from_user/copy_to_user wrapper in a number of other places, as this tends to produce the most readable version by concentrating the tricky logic in the one place that already has to be careful. Most of the bugs I've seen with compat code are from duplicated code paths that diverge over time when a bugfix for the native version is applied incorrectly or not at all to the compat version. Arnd 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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 2B630C433B4 for ; Tue, 18 May 2021 07:45:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AFE1F61285 for ; Tue, 18 May 2021 07:45:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFE1F61285 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2DDD96B00AB; Tue, 18 May 2021 03:45:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 267748E000C; Tue, 18 May 2021 03:45:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BC136B00AF; Tue, 18 May 2021 03:45:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id C9BB06B00AB for ; Tue, 18 May 2021 03:45:33 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6B9604DBD for ; Tue, 18 May 2021 07:45:33 +0000 (UTC) X-FDA: 78153566946.06.3888E0A Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf28.hostedemail.com (Postfix) with ESMTP id 906DE200024B for ; Tue, 18 May 2021 07:45:31 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 194EC6135F for ; Tue, 18 May 2021 07:45:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621323932; bh=Y+V2srtgNnzj+sz2D9W3MzRLHA3Oyb4L5KvaOMTQZcU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vK5VwonkDkZYGOJp6YPxhRKo6knrgsSkaAV/BX3HDLzqeEaTAA+6V1aM0uWRDthgO GA7xKHvqnbCcxPWVCRWRH2Taf9+f9jqeDMaFKjz1LKAzQsp9D0Hj6SKDK7AgkY9npN sg8FN/TpGhAqh4JO7a2DPGtzS2OTYOEWJSQhvhiGqNSA3PDbQL21zcnKcro361OA2B IBdhXiQuiIN9AqsY8tKloo056FxIXo4X+X7QWU4SkRt/RDz64TQOfPaQL97O5SNST4 pFYGuFPVxLVdQbqr6YF2uL28MgO9SvebKPyOiEI8oWODxf2w2ZWKAf0o1A9GfGxwqA TyrtMikqL9vqQ== Received: by mail-wr1-f42.google.com with SMTP id i17so9019420wrq.11 for ; Tue, 18 May 2021 00:45:32 -0700 (PDT) X-Gm-Message-State: AOAM533fjc07hueHI8CCkngyipdQ0IyUP0rvY5DjN6xuSFbE8lIT1hON 5GGK87AZpsTdtoDH9gPyK8WoKoX4Ij8ePV9xsKg= X-Google-Smtp-Source: ABdhPJzB9aNOakOhJJsNXyx8q3Jo6fxvkR8RjdO1U05M07un4qbYlL3TFt5Q+CmgOiR5uSU3DTozp5J+ZhaPeYV8A5U= X-Received: by 2002:a5d:5404:: with SMTP id g4mr5184734wrv.286.1621323930626; Tue, 18 May 2021 00:45:30 -0700 (PDT) MIME-Version: 1.0 References: <20210517203343.3941777-1-arnd@kernel.org> <20210517203343.3941777-2-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Tue, 18 May 2021 09:44:20 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/4] kexec: simplify compat_sys_kexec_load To: Christoph Hellwig Cc: "Eric W. Biederman" , linux-arch , Alexander Viro , Andrew Morton , Borislav Petkov , Brian Gerst , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Linux ARM , Linux Kernel Mailing List , Linux-MM , kexec@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=vK5Vwonk; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of arnd@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=arnd@kernel.org X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 906DE200024B X-Stat-Signature: 77q9rd58c697kpqeow3opytkiep4ndx6 X-HE-Tag: 1621323931-651291 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 Tue, May 18, 2021 at 8:40 AM Christoph Hellwig wrote: > > On Mon, May 17, 2021 at 10:57:24PM -0500, Eric W. Biederman wrote: > > We open ourselves up to bugs whenever we lie to the type system. > > > > Skimming through the code it looks like it should be possible > > to not need the in_compat_syscall and the casts to the wrong > > type by changing the order of the code a little bit. There are obviously other ways of doing the same. The reason for doing it this specific way is so I can eliminate the compat entry point entirely in patch 4/4. > What kind of bug do you expect? We must only copy from user addresses > once anyway. I've never seen bugs due the use of in_compat_syscall, > but plenty due to cruft code trying to avoid it. Right, I've used the same approach of passing a native-typed __user pointer and converting it in a copy_from_user/copy_to_user wrapper in a number of other places, as this tends to produce the most readable version by concentrating the tricky logic in the one place that already has to be careful. Most of the bugs I've seen with compat code are from duplicated code paths that diverge over time when a bugfix for the native version is applied incorrectly or not at all to the compat version. Arnd 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=-4.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 904F3C433ED for ; Tue, 18 May 2021 07:47:47 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 193266100A for ; Tue, 18 May 2021 07:47:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 193266100A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/Lli3mAHGXxEeJBTNvA/aIa1efg5X6CJWYoRgSX6OB8=; b=KtunU53y9NIe9I4oePHH/Pewi vm0Demk37HSVPVZXooSY+4RdVd90nZwKYF8IncCbsLg5YkThmdhznAupK+Y/Qh2jNEaqMXYzW+nst O4K3ksPxcPDHdADBcVYUe/xVcagO24KLeD9TNXuk8TdsGEXAuSYkm6NRmXHYofyqctV8Lrm9UvgyT GHmI3tPOgRI/uhYCplpOgLWCUIoGCdxmejXNd/JdR4zWQZblpbNt3GGjEeDLijeECxGTFlxKCo3Lb afWvyfy99UJYaTZf4Pt+KCJPLQAncAsk8ajpoGPLJ6FDQhFdlA0KREaQETI/dwVzUNl03pSEzEXRm xbFT+qcdQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1liuQ8-00HQg7-M1; Tue, 18 May 2021 07:45:40 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1liuQ2-00HQeR-Ov; Tue, 18 May 2021 07:45:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=gnNQM8JHHmfRWd04LwL/bJcm0BMPL6wiVW0KZ9ItLZM=; b=MKmn2r9i+2UKiBFcf6APwpbOpV DWEIU13xOu8IMeKvNo6bQznD+yCarGUWUqZNDBMnvjqu0zG0Az1e/+fU1P2tblHpe12AvK9dB1PTx JcV5m+VWi52Py3kPvCnykzcKGSUw/COn0yz21DjjiNOpbNvVodlxUxcsqjNB/RcTSoluIhob4h2j/ sgoffNAsQen6AEYr20c5NNWFFHCDvRqQWXJXPDIIvrY2/NiwOtffwL4+OHgKgLT2MkNIGUChcahWM 3jp7YOYjUeyRE/n7l6cU8BIVOJXVR/KtsDxo3DF31EG1hhsd7d9LQlpIVXmtaQvNIcIFIH4bBw6mm SfBMVjIQ==; Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1liuQ0-00EQVY-Bu; Tue, 18 May 2021 07:45:33 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id F1A94611BF; Tue, 18 May 2021 07:45:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621323932; bh=Y+V2srtgNnzj+sz2D9W3MzRLHA3Oyb4L5KvaOMTQZcU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=vK5VwonkDkZYGOJp6YPxhRKo6knrgsSkaAV/BX3HDLzqeEaTAA+6V1aM0uWRDthgO GA7xKHvqnbCcxPWVCRWRH2Taf9+f9jqeDMaFKjz1LKAzQsp9D0Hj6SKDK7AgkY9npN sg8FN/TpGhAqh4JO7a2DPGtzS2OTYOEWJSQhvhiGqNSA3PDbQL21zcnKcro361OA2B IBdhXiQuiIN9AqsY8tKloo056FxIXo4X+X7QWU4SkRt/RDz64TQOfPaQL97O5SNST4 pFYGuFPVxLVdQbqr6YF2uL28MgO9SvebKPyOiEI8oWODxf2w2ZWKAf0o1A9GfGxwqA TyrtMikqL9vqQ== Received: by mail-wr1-f49.google.com with SMTP id j14so7300018wrq.5; Tue, 18 May 2021 00:45:31 -0700 (PDT) X-Gm-Message-State: AOAM530BQA6nbIOBngzrqM8jNq6ADpOeQ5EPlMSDP49eRNytrkGaaBVc b8xE9MOvwMkDJZWbiOkqdGMHRCGKWyLpi0BQUME= X-Google-Smtp-Source: ABdhPJzB9aNOakOhJJsNXyx8q3Jo6fxvkR8RjdO1U05M07un4qbYlL3TFt5Q+CmgOiR5uSU3DTozp5J+ZhaPeYV8A5U= X-Received: by 2002:a5d:5404:: with SMTP id g4mr5184734wrv.286.1621323930626; Tue, 18 May 2021 00:45:30 -0700 (PDT) MIME-Version: 1.0 References: <20210517203343.3941777-1-arnd@kernel.org> <20210517203343.3941777-2-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Tue, 18 May 2021 09:44:20 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/4] kexec: simplify compat_sys_kexec_load To: Christoph Hellwig Cc: "Eric W. Biederman" , linux-arch , Alexander Viro , Andrew Morton , Borislav Petkov , Brian Gerst , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Linux ARM , Linux Kernel Mailing List , Linux-MM , kexec@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210518_004532_445732_A4A61956 X-CRM114-Status: GOOD ( 21.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, May 18, 2021 at 8:40 AM Christoph Hellwig wrote: > > On Mon, May 17, 2021 at 10:57:24PM -0500, Eric W. Biederman wrote: > > We open ourselves up to bugs whenever we lie to the type system. > > > > Skimming through the code it looks like it should be possible > > to not need the in_compat_syscall and the casts to the wrong > > type by changing the order of the code a little bit. There are obviously other ways of doing the same. The reason for doing it this specific way is so I can eliminate the compat entry point entirely in patch 4/4. > What kind of bug do you expect? We must only copy from user addresses > once anyway. I've never seen bugs due the use of in_compat_syscall, > but plenty due to cruft code trying to avoid it. Right, I've used the same approach of passing a native-typed __user pointer and converting it in a copy_from_user/copy_to_user wrapper in a number of other places, as this tends to produce the most readable version by concentrating the tricky logic in the one place that already has to be careful. Most of the bugs I've seen with compat code are from duplicated code paths that diverge over time when a bugfix for the native version is applied incorrectly or not at all to the compat version. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: MIME-Version: 1.0 References: <20210517203343.3941777-1-arnd@kernel.org> <20210517203343.3941777-2-arnd@kernel.org> In-Reply-To: From: Arnd Bergmann Date: Tue, 18 May 2021 09:44:20 +0200 Message-ID: Subject: Re: [PATCH v3 1/4] kexec: simplify compat_sys_kexec_load List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Christoph Hellwig Cc: "Eric W. Biederman" , linux-arch , Alexander Viro , Andrew Morton , Borislav Petkov , Brian Gerst , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Linux ARM , Linux Kernel Mailing List , Linux-MM , kexec@lists.infradead.org On Tue, May 18, 2021 at 8:40 AM Christoph Hellwig wrote: > > On Mon, May 17, 2021 at 10:57:24PM -0500, Eric W. Biederman wrote: > > We open ourselves up to bugs whenever we lie to the type system. > > > > Skimming through the code it looks like it should be possible > > to not need the in_compat_syscall and the casts to the wrong > > type by changing the order of the code a little bit. There are obviously other ways of doing the same. The reason for doing it this specific way is so I can eliminate the compat entry point entirely in patch 4/4. > What kind of bug do you expect? We must only copy from user addresses > once anyway. I've never seen bugs due the use of in_compat_syscall, > but plenty due to cruft code trying to avoid it. Right, I've used the same approach of passing a native-typed __user pointer and converting it in a copy_from_user/copy_to_user wrapper in a number of other places, as this tends to produce the most readable version by concentrating the tricky logic in the one place that already has to be careful. Most of the bugs I've seen with compat code are from duplicated code paths that diverge over time when a bugfix for the native version is applied incorrectly or not at all to the compat version. Arnd _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec