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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEDE7C54798 for ; Tue, 5 Mar 2024 09:32:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7821E6B0085; Tue, 5 Mar 2024 04:32:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 70BE56B0095; Tue, 5 Mar 2024 04:32:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 584FA6B0096; Tue, 5 Mar 2024 04:32:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 425CD6B0085 for ; Tue, 5 Mar 2024 04:32:10 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 085E61A0301 for ; Tue, 5 Mar 2024 09:32:10 +0000 (UTC) X-FDA: 81862469220.11.E3A5F94 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by imf09.hostedemail.com (Postfix) with ESMTP id 18D38140019 for ; Tue, 5 Mar 2024 09:32:06 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=EsIISdsE; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf09.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.182 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709631127; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jwQHCS1RApRdLMtnfYY4Lo44hm6+L8NjNwQTBjGnVfA=; b=m56CRs213Xu4eBY6uTpauXppWrQiuqkWE9vw14VkPhzrHUugYNbIk9TZEQ8nAE6oGRAMEE zuKSXyqtSchl/Sp8bTSLMmBGJGM7dCsbmva8thDWRo38gt+YaJhvMgsEcz2RVu02/DTuyt IRdWhre/SXpWsDiX5h8UhlN+/+zrma4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=EsIISdsE; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf09.hostedemail.com: domain of keescook@chromium.org designates 209.85.214.182 as permitted sender) smtp.mailfrom=keescook@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709631127; a=rsa-sha256; cv=none; b=K4DYvhYo5qz7D/1NT6Gwc/k41QvKXQVK4OlTeMcw74E0T+Cl+X3Vuo82z+Ycq2fCN1DMIv DHnCc0BNE6c6cN+rNBuXUhpmfz1QQDGwhBpKZ9SBLI2ADZXByN538sPAyXPYONv0Y0gk5A WxhNGu3DSG9PKeiwPL/iKqQRh3JlAyA= Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-1dccb2edc6dso45202575ad.3 for ; Tue, 05 Mar 2024 01:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1709631126; x=1710235926; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=jwQHCS1RApRdLMtnfYY4Lo44hm6+L8NjNwQTBjGnVfA=; b=EsIISdsEHfB7hVIftc5kvZCWLcGVxfAOFHhMnCVf+gerPUMQEzcgtAnlJm9bs36SEe +wzi294FneTrprWQDtXWxLsyj2KBQbeL5MncAX+qzKp3r7W0tb2N+25A5bZ+eBxJ6qlm +/3gGAAkI3SFPsbSvk/Cr52WOz9yvRi6iC8Jw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709631126; x=1710235926; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jwQHCS1RApRdLMtnfYY4Lo44hm6+L8NjNwQTBjGnVfA=; b=ImmbRC09f8BCDWvkyDN5dSJYhdzjnCZIG0Z1ftJtmppIZ3EepBKiOMs3W2lmELl0UY 1+bWrtqm0UDfx4xHlkvLpkNddWDZnlBaytp0oZEUnK5Rju+dPg35nHHepS4Jp4GJmiA2 /8ejdt2mhFT1jjFBzB8SAYSVBp+B8mj5I52wZ6ew7ocxsyZlBzEn6dCNSCPNohJNZcQ5 waaw6nFwjbnARdo1rYJDG2rnFNJSWLhl1cdVI0mG1dt0S3bc5f8FEfYX7Qzk84G0jHnJ D5MJ7lhcA2BJKwB5qndEUw6MF5HxsZ9B9T6A2880cINgoYMXok6Ld9wRX2Zwz9e3o3OG lzFA== X-Forwarded-Encrypted: i=1; AJvYcCVCRqwvlDiNLAcOraAwweV+nvhVrHuUgnlknNHKDYvKp9ADv2EsH5dN/9+Hj7bkESHis3rxaOi48aSyeNIRYa3v31A= X-Gm-Message-State: AOJu0YwbTXaQKuu0qgDo8uhjOXGNJyqHEUogoXkFl3/6YE5s50UD6I1X 8uBnzY+ECsryLDGERBqXDCJ7Ka8xswYYWLIR5JHo8qaFWX/W8c5V3C0owX2cnA== X-Google-Smtp-Source: AGHT+IEkIjd9sE8/PNSfNzhkY5QnMDDggNLePYzvx388RJGPnJJiHoeKZ/QNY7uY/4Q61sqgAgAuEg== X-Received: by 2002:a17:902:a50e:b0:1dc:66da:d21a with SMTP id s14-20020a170902a50e00b001dc66dad21amr1054443plq.28.1709631125912; Tue, 05 Mar 2024 01:32:05 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id im15-20020a170902bb0f00b001db5c8202a4sm10192588plb.59.2024.03.05.01.32.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Mar 2024 01:32:05 -0800 (PST) Date: Tue, 5 Mar 2024 01:32:04 -0800 From: Kees Cook To: Jiangfeng Xiao Cc: Jann Horn , gustavoars@kernel.org, akpm@linux-foundation.org, jpoimboe@kernel.org, peterz@infradead.org, dave.hansen@linux.intel.com, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, nixiaoming@huawei.com, kepler.chenxin@huawei.com, wangbing6@huawei.com, wangfangpeng1@huawei.com, douzhaolei@huawei.com Subject: Re: [PATCH] usercopy: delete __noreturn from usercopy_abort Message-ID: <202403050129.5B72ACAA0D@keescook> References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <202403040938.D770633@keescook> <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 18D38140019 X-Stat-Signature: oe1frxx8cye3xkgp97ptebhzy3a6eq3k X-Rspam-User: X-HE-Tag: 1709631126-253565 X-HE-Meta: U2FsdGVkX19JX6ohJJ+tsvaRSZ3o7f7wEEYzdxws3MwWnpotHb/QMCjMn74GRTSk0tFjtQyUaqw5rkuUFRT2FS0xo9naBBv76Imq1J6QxmzjaK+ACmNyiUDQaoVgzTs4Eogoc5ANol0YCgobc6eLm+er2Ydo8CAtKHchzEOdkKWLIDilgMhvNO3Dl+RtvugijrexoblJGDueimeLYdyfNO8kLjZQhMl6m7PkuMBLlFd59sMKAjYeY+vEqehCDj/aKurBM1nFwrbmSa3fmraaSqaB4+ZX0RltnTXsYHhd9FHTasVT2GSQcz/vJVRc73+jRSYLsGSElPo8ehdJOGfa+wntXZdeg68QToYyxTf3QlsfHWygI5kSRc7890J+a51eUhwmWcF4yK0KZifUoLUCaJ9xPzUzNG0pe9LdePaFIGHkD6aqtDiCv5ljUugbl9C8hzscFYWngnS/FzqWmV4pz1FG6JeohLcPhacRZehrVOl3Y9IhiRh5ppiwlD1fyaEbWCBDmOXf9bz+SNCR30rp1Jd8DKIZ3s1YgxjyB/z9wpkCY2mvc8EWxokN8RTFqAwrY6ce3w6x1qVdN2huXUsV9XhR/HGQrKT/q1+uBDwfPLsxaAURuiqQdO4/P3DJGZQVak1Z97AAWl+MCu8vzKhFZs2Ff1xGzuLpYqGgjgfvwLEPrMLohG9YmZzI2kj8nJH7hiiiwnu7Ghzd3hjGQx5iOESZiPz7OuGNxJWRsWntsWEV8s1TjxY0n7Bt1MsXWITObYgzD+PTTo1TJYf5LK0jA+CBkxypygEucOiMbormbcPkStjRUptNYvByL9Q3pUyoMZrtjqHiQPEH5rdO/OZSmuQDQ301qmHf9vCYGa60m+iBCmWwFg0/yckuAtXL0He7DpSrOlhaUJUYSfaflbFiwIck0tzv7l5IpXroCjEg3bXy68hqUZnahEOZ4iM6Yvhbw3oTubHNFFBULJ7i+Ya 1C9tUda4 m/5thhQfc2jdfXT2gDE0XXpWqCnsF8JA1p8pcJ/qBMyHNysZZxUVvDAPO0yOoEdg9X4L8MKayVxvUxHQeQfb7ywRJgZQfcOXlSdkrn4j15tCtkkJ3H5n4YvsHTpEFWDvX2P8dHO+9sHaNHCLicnLZIsYq471vzIb7XjVkvYKX1BmP9jbyeUZXmapOWI1+1xqi1gpfUHZOOJuefsj0dpkhg8+cjkLDTcEDg5W+5ii+j7M90N4mscgLtbiAvrpyxyDsO9xOexBjUqBEyEN+992ZDSeHFGRQppzdiAlVPd1x+HpK5irAg4q1oLmcAZw8TPm3MCDbzVMhVhxALmdqkRz+pYmPjwG735hjN2uivrrepqdwFk1hgwdNIRpZq1LExEhpgSIQFMhaY5Krwmn+VC9M9VMYpfutzcC7VzXAK1zgWkAvlqW6Mwl0exJDlRoOAbbmEAQm X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 05, 2024 at 11:31:06AM +0800, Jiangfeng Xiao wrote: > > > On 2024/3/5 1:40, Kees Cook wrote: > > On Mon, Mar 04, 2024 at 04:15:07PM +0100, Jann Horn wrote: > >> On Mon, Mar 4, 2024 at 3:02 AM Jiangfeng Xiao wrote: > >>> When the last instruction of a noreturn function is a call > >>> to another function, the return address falls outside > >>> of the function boundary. This seems to cause kernel > >>> to interrupt the backtrace. > > > > FWIW, all email from huawei.com continues to get eaten by anti-spam > > checking. I've reported this a few times -- it'd be really nice if the > > domain configuration could get fixed. > > > >> [...] > >>> Delete __noreturn from usercopy_abort, > >> > >> This sounds like the actual bug is in the backtracing logic? I don't > >> think removing __noreturn annotations from an individual function is a > >> good fix, since the same thing can happen with other __noreturn > >> functions depending on what choices the compiler makes. > > > > Yeah, NAK. usercopy_abort() doesn't return. It ends with BUG(). > > > When the user directly or indirectly calls usercopy_abort, > the final call stack is incorrect, and the > code where the problem occurs cannot be located. > In this case, the user will be frustrated. Can you please give an example of this? > For the usercopy_abort function, whether '__noreturn' is added > does not affect the internal behavior of the usercopy_abort function. > Therefore, it is recommended that '__noreturn' be deleted > so that backtrace can work properly. This isn't acceptable. Removing __noreturn this will break objtool's processing of execution flow for livepatching, IBT, and KCFI instrumentation. These all depend on an accurate control flow descriptions, and usercopy_abort is correctly marked __noreturn. -- Kees Cook