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 9DA9EC54E41 for ; Tue, 5 Mar 2024 11:38:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E45366B009F; Tue, 5 Mar 2024 06:38:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF51F6B00A0; Tue, 5 Mar 2024 06:38:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBC076B00A1; Tue, 5 Mar 2024 06:38:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B88986B009F for ; Tue, 5 Mar 2024 06:38:58 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 8C95D160E59 for ; Tue, 5 Mar 2024 11:38:58 +0000 (UTC) X-FDA: 81862788756.04.85E76CC Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf02.hostedemail.com (Postfix) with ESMTP id 08B5580013 for ; Tue, 5 Mar 2024 11:38:55 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709638736; 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; bh=ChT0ZNsfEzkq1D397OiZVdr+W8hcvaiS0J2vI6GLNCg=; b=YF68r8UVSG1PJx1QkIkKFFwFBxCP4LM1mEYLB4gqh+ZuVRNv6aWJL6YsaHzPLFxuCBghFE 5jbOHbReB/B1i53U2r0uvuWnD6d3512uFuR6JUSfzg+NQ68KniwEsLiAt1YFir0pcy8zKm n3/zigCzMO7s4XAWtKk7fYe8le9Lmg8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709638736; a=rsa-sha256; cv=none; b=wmFJAjJLH+rNxaZwpYXkWVd4VKq5iXJu6ViGUA6kQVJvi2Bnjt3TD9+sw+Ih5i9862Sp3u MYqc2k6irheoe0RoSk1qDX26JKybuu/Rf/DBVIN/shsl+FPqsUMhmIQAnUMiHzYTIufng4 KZgzyN1Pbot6hgObfW2U5xArv3HMSrI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none; spf=pass (imf02.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4TptnG4ZB0zwPDy; Tue, 5 Mar 2024 19:36:34 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id 1C24F1400C8; Tue, 5 Mar 2024 19:38:51 +0800 (CST) Received: from [10.67.111.82] (10.67.111.82) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Tue, 5 Mar 2024 19:38:50 +0800 Subject: Re: [PATCH] usercopy: delete __noreturn from usercopy_abort To: Kees Cook References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <202403040938.D770633@keescook> <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com> <202403050129.5B72ACAA0D@keescook> CC: Jann Horn , , , , , , , , , , , , , , From: Jiangfeng Xiao Message-ID: Date: Tue, 5 Mar 2024 19:38:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <202403050129.5B72ACAA0D@keescook> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.111.82] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500010.china.huawei.com (7.192.105.118) X-Stat-Signature: yr43e3ew3ppf5cjfrgdsmtrjiht73ug5 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 08B5580013 X-Rspam-User: X-HE-Tag: 1709638735-734543 X-HE-Meta: U2FsdGVkX1+AISc7a/LvJAR3flVCNpdxeS0/u1aRgch5UZ35VU9oHCRvY5j3qbJmZ5TKuyBMFPUjTkjYqpOibpGgrz4xx4e0xU42iXv2e+OP/OB/IOavsoWjrwtKhfAw2fEwg7TKfoG37iO8j6yzRy/wVEn2bI1GvMRlsWwz2YlskGZ+2ipLNexqmUViRBW1517DbZiqzXmqj2QzaPfBREJEhUpKo5tLXcHfK8qIbH3K57rI5iJZ0r6PcmA4eSceDkNNVyCTIof6am5SpY+a+oOCqPQw+IRNbf30pqr4v7XEYoPNxbeCJHfxqTXR5FurDEtZhtkyMlPHFWStmOyaCaZPzPwEtNBevsWmIrV+39K8+AU9q0m6zrKv1iokPeduEbb9QUofOg7xpB1yHmKnh0G5uRrIqVKJz5XMMUf+QhlzI7OKVDJZH9SR3THOq22BScoYiEzg8suAV3kh9yvhU1YaEqw3PaZjEfSuQK95uRdBgG0QVieRilQfrw/0nGZf3WJfdgHCY2i22HZtgye1DHDzIfBCvW+La0X3xTNTN5ErUgFNtkDg+uf32Fz/AZe9fGcWcfNTlnuDbdwmmyrNwK74BPpgw9NWVKpZbzaFCCun9j6Aj6WfOczehnS3EETEH3UTHDk2/ai3DMtK7XJnnMgngZyX3aGZPzYTLBCZ+o3N2vu+bzDtXJheBHsNxoirbjEzCTqzhRjjZPhR0yzPhPx8j/b+suIUWmFlaB2hyPL1TcimwZkeVvmhN0g8N9MOK7Ksh62mfitwAD/t5xAgc1L/3MwL8sIwJ/QPBkTtrhEa2SJz1PoPooe34TfQc3zFvSLRKd5pLylgh/6sZzDFBIrSUGubM71a7UTPvsR9azrwMzwQJbyQ6PKEe2jS2UtLvxEdCuyLa75U7/1/Qog3FqR+3gwDdEwnqXD8Hv9ir7eqinESCycKaCylrluZ3AqYOnBQOx9UJ//SFB9wKL1 PAwCeSqy /B4NCoIOsLis4rJB+C67WD9gI9ATqsmujQJIiwtUZ2OqpFe1uAh36nEP/eMZ7zt0eswqTy3Rc3FLMqKIYH07R5FF7baUffpRE+YnLxB9cDKazyV0H2HpT9Xhsrf+9J4hvc8aIjtWOMQkEc7wJV7MWZ7hhUGPPZ1ryQRYGhXd4MXU2UlG7eLYGPoTrP/xPzbaBAEkVztT4ak5nYOA= 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: List-Subscribe: List-Unsubscribe: On 2024/3/5 17:32, Kees Cook wrote: > 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? The main configurations of my kernel are as follows: CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is enabled. (This config uses the compilation parameter -O2.) CONFIG_RELOCATABLE is disabled. (This config uses the compilation option -fpic.) You can use the following kernel module testcase to reproduce this problem on the ARM32 platform. ``` #include #include static volatile size_t unconst = 0; /* check_object_size __check_object_size check_kernel_text_object usercopy_abort("kernel text", ...) */ void test_usercopy_kernel(void) { check_object_size(schedule, unconst + PAGE_SIZE, 1); } static int __init test_usercopy_init(void) { test_usercopy_kernel(); return 0; } static void __exit test_usercopy_exit(void) { } module_init(test_usercopy_init); module_exit(test_usercopy_exit); MODULE_LICENSE("GPL"); ``` > >> 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. > Thank you for providing this information. I'll go back to further understand how __noreturn is used in features such as KCFI and livepatching.