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 DFCC4C71153 for ; Tue, 29 Aug 2023 16:49:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 419FA8E0029; Tue, 29 Aug 2023 12:49:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CA348E001A; Tue, 29 Aug 2023 12:49:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 24E408E0029; Tue, 29 Aug 2023 12:49:46 -0400 (EDT) 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 129FC8E001A for ; Tue, 29 Aug 2023 12:49:46 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C90381A0205 for ; Tue, 29 Aug 2023 16:49:45 +0000 (UTC) X-FDA: 81177728730.24.4713D0F Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf22.hostedemail.com (Postfix) with ESMTP id A9610C0019 for ; Tue, 29 Aug 2023 16:49:42 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf22.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693327782; 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: in-reply-to:in-reply-to:references:references; bh=aIriRu1Q+ItjnGiPKTX7rDeDd4Mxe6Hm1hxXuuUelME=; b=aSlLy6iqHi1H8SRsbbUJ9sdum+jYfKwdYc9cthfKviGD7XrjM6e4WBoY1baqYIB8Hclgzz y0soUtVlxf6KdZC6GjD0Vxqwzjhz5PbeW2gENvbn8xfy++ozuhUqCu2MBpmzdDOEOkvbRW OZMsRayr5LpryvYHE8LaNkGfE1fsrfE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=xmission.com; spf=pass (imf22.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.231 as permitted sender) smtp.mailfrom=ebiederm@xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693327782; a=rsa-sha256; cv=none; b=BaqfGXlAMO7W8rfQ4Yt5rpIXfKSemYe5whYXZkoHPYiZYQ9+8AViptdlLStE2zS/LUmnEr JUQf0cku0JypnqJSPM9uLdscfWMeqK5bHmQv4LlwMkMxe+9U0I8+T0x2SJXMryyqIlY6ph 7JWbgRbfsXd+V4u3UPLs430WHapZTEY= Received: from in01.mta.xmission.com ([166.70.13.51]:51814) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qb1uO-005Upo-Bu; Tue, 29 Aug 2023 10:49:40 -0600 Received: from ip68-227-168-167.om.om.cox.net ([68.227.168.167]:55818 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1qb1uN-00CWYq-DY; Tue, 29 Aug 2023 10:49:40 -0600 From: "Eric W. Biederman" To: Alejandro Colomar Cc: Matthew Wilcox , David Howells , Kees Cook , linux-mm@kvack.org, Rolf Eike Beer , Arnd Bergmann , Thomas Gleixner , "Paul E. McKenney" , Dave Jones References: <926f8e5c-40bd-dae0-2492-f6e6dbd6c96e@kernel.org> <8a7df4fd-9cf6-9a2e-feec-1c70197ed5fa@kernel.org> Date: Tue, 29 Aug 2023 11:48:49 -0500 In-Reply-To: <8a7df4fd-9cf6-9a2e-feec-1c70197ed5fa@kernel.org> (Alejandro Colomar's message of "Tue, 29 Aug 2023 16:20:42 +0200") Message-ID: <87wmxdokum.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1qb1uN-00CWYq-DY;;;mid=<87wmxdokum.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.168.167;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX1+scLHPh3V1UuQxZ8QFatAsWvh6vccxS+g= X-SA-Exim-Connect-IP: 68.227.168.167 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: 'struct dynamic': struct tag leak in UAPI headers X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-Rspamd-Queue-Id: A9610C0019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: i8pr8c9rj14e96erpp1u1x9zfn8cntub X-HE-Tag: 1693327782-266151 X-HE-Meta: U2FsdGVkX1/hux+axLwq5LSuATOgYFG/3enooEgpG7uNfqJx+tuodcftvo+l+aJqvuvy44FWB1OxRhP9L7H6dv3md1qu1bZBzsDMib5rag0qyXAipMsa4OBunJ7d2y5zgPrh7VfPTgs5BipD0mB6DTDq4hm/0JwoqTOEj6jhssIa6ReVnicLdcNAVY0FseO7v4t7Vz5L5eszqiC3lXecC8EDK8gDb3zb0Bw0Hnf02ubqWjfieajr8PslZpfQlFU0pPScfH9RTRMon4Ar700m1+goPT2J4iQbWU8LKMNtBRgKjMFBAJ4QeSk8wCeoNxWgW5SNr9vibUx7dRzgR6A+9ARvfHuMsYkhjq88QbZWJJLxScWuATJFmyftnK/8amQfJlOQ+n0CUnE04FeaP4XK0kG3/hQ5b/WbyRy/kb+cmdFYBXvZorDNhtSixxvOC2fVn3l7VUZ9PhE1Ujf/RZLrHwdPfzOexTVZ0/8eME1OIUlKuwzqIi9k1oQ+npbVHu2kkynVu8tKLmO48QCG6BUhVlqG792NE2sJjYVzcKGxF3hXQcb7BrndebROY9CjRUhk6odyyNyeFWooYGJg53Qfokfkx55NbRCmZWSqTyuzZWuAzm2j1oA92gLoyisamFzFCc3zvSlNc/wRokISx2HNR4BOeZ8LEG03A0ykBqD/wlxyI3gy2pRO+1P9jzEAGygSDS10K2vA+4tonpOZ0JIOYjtJaqLSgnAtZBJXht/DGz17opH3kWEvSRTHEwClxtoAzvNaLie5XOUldf7ckOZyy2Atr6iAdSPNi8hWCAjn8XoV44Vqu1nmBEwjvB91byVYUyTPhEWX6tfmmvpNHyhWwQfu32VHRMXUukjjj2jdfVsCnAdxirUZOFoR9zP5eZj6CMtPSVFKnAJKz2zb0LWr7Wy/nS3pkc3KK6c5ihbdd4XOn10RnF0lCYLMhLhAjIz7X4rr62JMKhEuQ4mDEks o6re1STF 9n0JeDZTuBztnziY1/vTlcFhx3tu7eHaIbeGty++WJLJrdaU7IEh4T2qM6S0t2EAT9zYywBpIDZqsQBmYFtu6K5HSWA== 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: Alejandro Colomar writes: > On 2023-08-29 16:17, Matthew Wilcox wrote: >> Ooh, story time! Long, long ago, we did not separate "Linux headers" >> from "libc headers". It used to be somebody's job to take the files >> in /usr/src/linux/include/linux and copy them to /usr/include/linux. >> Bold people used a symlink. People who cared about things like "Well, >> POSIX says that" would edit the files after copying them to remove things >> that POSIX said shouldn't be there or put _GNU_SOURCE markers around them. >> >> At some point, we decided to split the headers to create the uapi headers >> to make this job easier. Refinements are, of course, possible, and now >> easier than ever, but I think it's fair to say that anybody who included >> at any time in history got given a struct dynamic. > > Thanks for the story! :-) > > >> Well, it's a compile-time failure either way. Code that depended on it >> is compiling happily today, and the code that would want to use it >> doesn't exist yet, so I'd rather err on the side of keeping code written >> in the last 30 years working. > > Fair enough. The kernel rules do allow removing the structure tag if we no one is using it. If someone is using it then the bug is a regression. If you have the energy you can do a good faith search to see if there is any likely hood that anyone is using it. At a quick look I don't see anything including linux/elf.h. Add in a debian code search (is there a github or gitlab code search?) and you can make a pretty firm dent how widespread that is. After a good faith search you can merge a patch to remove it, and then if anyone reports a problem because you somehow missed them you can revert the change. If anything like libc that wants to very carefully control it's exported symbols wants to use linux/elf.h it is probably worth it. Otherwise it is probably more work that it is worth. Eric