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=-10.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 10E16C47093 for ; Wed, 2 Jun 2021 20:15:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8E8B613D2 for ; Wed, 2 Jun 2021 20:15:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229789AbhFBUQy (ORCPT ); Wed, 2 Jun 2021 16:16:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229552AbhFBUQw (ORCPT ); Wed, 2 Jun 2021 16:16:52 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A85CC061756; Wed, 2 Jun 2021 13:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hg1i1lJUDI2dbeh2/KVZj893kEGRfKzlm3YByZ5waG8=; b=pw5LtsnUBCH9bK2J0dEulMays omr8kMIj1brZGBhcbDHrAae/h+L4FnbWtFLgTbPNrmeMqEkbEcgl4Vz7SE8RqRsvtZ6UbqRIVF0Qq iVX2dypzeNwFOS7Px9gyAZA0B0cGjui2nj9yoXNL6zBKZcwA1okNTEnf6qTDQz0h0QIugSNpDBxlQ BCoYuqDSMNOafq7kf12tLMf+P7f6DryHtuIjU1b5dWa5tD21VEwQbqwQFL81W8vebifiK8hc5Szfy EPHT3nsn+EYbrK5t/g8EAFQt2VIIKN7AEZEMInO4I1pJxIKvV5srYPBdZ/+CRQjiSMoxOKI6LVow9 XqvY+jujw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44646) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loXGa-0001mw-OQ; Wed, 02 Jun 2021 21:15:04 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1loXGY-0001QE-UG; Wed, 02 Jun 2021 21:15:02 +0100 Date: Wed, 2 Jun 2021 21:15:02 +0100 From: "Russell King (Oracle)" To: Mike Rapoport Cc: Mike Rapoport , linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christian Borntraeger , David Hildenbrand , Heiko Carstens , Thomas Bogendoerfer , Vasily Gorbik , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org Subject: Re: [RFC/RFT PATCH 2/5] memblock: introduce generic memblock_setup_resources() Message-ID: <20210602201502.GP30436@shell.armlinux.org.uk> References: <20210531122959.23499-1-rppt@kernel.org> <20210531122959.23499-3-rppt@kernel.org> <20210601135415.GZ30436@shell.armlinux.org.uk> <20210602101521.GD30436@shell.armlinux.org.uk> <20210602155141.GM30436@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 02, 2021 at 09:43:32PM +0300, Mike Rapoport wrote: > Back then when __ex_table was moved from .data section, _sdata and _edata > were part of the .data section. Today they are not. So something like the > patch below will ensure for instance that __ex_table would be a part of > "Kernel data" in /proc/iomem without moving it to the .data section: > > diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S > index f7f4620d59c3..2991feceab31 100644 > --- a/arch/arm/kernel/vmlinux.lds.S > +++ b/arch/arm/kernel/vmlinux.lds.S > @@ -72,13 +72,6 @@ SECTIONS > > RO_DATA(PAGE_SIZE) > > - . = ALIGN(4); > - __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { > - __start___ex_table = .; > - ARM_MMU_KEEP(*(__ex_table)) > - __stop___ex_table = .; > - } > - > #ifdef CONFIG_ARM_UNWIND > ARM_UNWIND_SECTIONS > #endif > @@ -143,6 +136,14 @@ SECTIONS > __init_end = .; > > _sdata = .; > + > + . = ALIGN(4); > + __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { > + __start___ex_table = .; > + ARM_MMU_KEEP(*(__ex_table)) > + __stop___ex_table = .; > + } > + > RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE) > _edata = .; This example has undesirable security implications. It moves the exception table out of the read-only mappings into the read-write mappings, thereby providing a way for an attacker to bypass the read-only protection on the kernel and manipulate code pointers at potentially known addresses for distro built kernels. > I agree there is a risk but I don't think it's high. It does not look like > the minor changes in "reserved" reporting in /proc/iomem will break kexec > tooling. What makes you come to that conclusion? The kexec tools architecture backends get to decide what they do when parsing /proc/iomem. Currently, only firmware areas are marked reserved in /proc/iomem on 32-bit ARM. This is read by kexec, and entered into its memory_range[] table as either RAM, or RESERVED. kexec uses this to search for a suitable hole in the memory map to place the kernel in physical memory. The addition of what I will call ficticious "reserved" areas by the host kernel because the host kernel happened to use them _will_ have an impact on this. They _are_ ficticious, because they are purely an artifact of the host kernel being run, and are of no consequence to tooling such as kexec. What such tooling is interested in is which areas it needs to avoid because of firmware. I think what isn't helping here is that you haven't adequately described what your overall objective actually is. Framing it in terms of wanting the reserved memory to be consistent between the various kernel "interfaces" such as /proc/iomem, the memblock debugfs and firmware is very ambiguous and open to different interpretations, whcih I think is what the problem is here. > Anyway the amount of reserved and free memory depends on a > particular system, kernel version, configuration and command line. > I have no intention to report kernel boot time reservations > to /proc/iomem on architectures that do not report them there today, > although this also does not seem like a significant factor. You seem to be missing the point I've tried to make. The areas in memblock that are marked "reserved" are the areas of reserved memory from the firmware _plus_ the areas that the kernel has made during boot which are of no consequence to userspace. Wanting /proc/iomem, memblock and firmware to all agree on the values that they mark as "reserved" is IMHO unrealistic. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! 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=-10.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 EFBECC4708F for ; Wed, 2 Jun 2021 20:16:51 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 AE080600D4 for ; Wed, 2 Jun 2021 20:16:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE080600D4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=armlinux.org.uk 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=u2goVwJcRNdDUSiuSR5uBs3ZBce3bYXBREr+590UTok=; b=ViXS/+mWY3Z7j3 w6O2z5d9uJ8XuTA1tvHA9esOUMkdEqCkjUGxKB97gJKKN+64owDuBow6YcD0DO6yDYNwxqft+nRLp B//ERa5gtXIurLyiDZ0m2sG+yHWjg9o8VFD+B8ULPWGNz7VHv2SGrsbllJo4f6KfOE+KIbb+Gx6JH ytdNJif/0x0hBt9XpCkwWmnY50m7GErtmpNxjL+ppH4/iqD3dwuFdWBH9ni52IXJ4bmgMcjcuLPBR PM4sk6PL9kv2GgiKTYsOftdoCuoWHg0FfR0m0siRJrci3yk9JDuJoy/hzaB3RQsGA1yttkYKNYmNf nEXzhQ5SLrXq4lgPqSzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1loXGq-0066WF-SM; Wed, 02 Jun 2021 20:15:21 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1loXGm-0066RG-IR for linux-arm-kernel@lists.infradead.org; Wed, 02 Jun 2021 20:15:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hg1i1lJUDI2dbeh2/KVZj893kEGRfKzlm3YByZ5waG8=; b=pw5LtsnUBCH9bK2J0dEulMays omr8kMIj1brZGBhcbDHrAae/h+L4FnbWtFLgTbPNrmeMqEkbEcgl4Vz7SE8RqRsvtZ6UbqRIVF0Qq iVX2dypzeNwFOS7Px9gyAZA0B0cGjui2nj9yoXNL6zBKZcwA1okNTEnf6qTDQz0h0QIugSNpDBxlQ BCoYuqDSMNOafq7kf12tLMf+P7f6DryHtuIjU1b5dWa5tD21VEwQbqwQFL81W8vebifiK8hc5Szfy EPHT3nsn+EYbrK5t/g8EAFQt2VIIKN7AEZEMInO4I1pJxIKvV5srYPBdZ/+CRQjiSMoxOKI6LVow9 XqvY+jujw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:44646) by pandora.armlinux.org.uk with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loXGa-0001mw-OQ; Wed, 02 Jun 2021 21:15:04 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.92) (envelope-from ) id 1loXGY-0001QE-UG; Wed, 02 Jun 2021 21:15:02 +0100 Date: Wed, 2 Jun 2021 21:15:02 +0100 From: "Russell King (Oracle)" To: Mike Rapoport Cc: Mike Rapoport , linux-kernel@vger.kernel.org, Andrew Morton , Catalin Marinas , Christian Borntraeger , David Hildenbrand , Heiko Carstens , Thomas Bogendoerfer , Vasily Gorbik , Will Deacon , linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org Subject: Re: [RFC/RFT PATCH 2/5] memblock: introduce generic memblock_setup_resources() Message-ID: <20210602201502.GP30436@shell.armlinux.org.uk> References: <20210531122959.23499-1-rppt@kernel.org> <20210531122959.23499-3-rppt@kernel.org> <20210601135415.GZ30436@shell.armlinux.org.uk> <20210602101521.GD30436@shell.armlinux.org.uk> <20210602155141.GM30436@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210602_131516_643353_1690B7D1 X-CRM114-Status: GOOD ( 27.04 ) 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 Wed, Jun 02, 2021 at 09:43:32PM +0300, Mike Rapoport wrote: > Back then when __ex_table was moved from .data section, _sdata and _edata > were part of the .data section. Today they are not. So something like the > patch below will ensure for instance that __ex_table would be a part of > "Kernel data" in /proc/iomem without moving it to the .data section: > > diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S > index f7f4620d59c3..2991feceab31 100644 > --- a/arch/arm/kernel/vmlinux.lds.S > +++ b/arch/arm/kernel/vmlinux.lds.S > @@ -72,13 +72,6 @@ SECTIONS > > RO_DATA(PAGE_SIZE) > > - . = ALIGN(4); > - __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { > - __start___ex_table = .; > - ARM_MMU_KEEP(*(__ex_table)) > - __stop___ex_table = .; > - } > - > #ifdef CONFIG_ARM_UNWIND > ARM_UNWIND_SECTIONS > #endif > @@ -143,6 +136,14 @@ SECTIONS > __init_end = .; > > _sdata = .; > + > + . = ALIGN(4); > + __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) { > + __start___ex_table = .; > + ARM_MMU_KEEP(*(__ex_table)) > + __stop___ex_table = .; > + } > + > RW_DATA(L1_CACHE_BYTES, PAGE_SIZE, THREAD_SIZE) > _edata = .; This example has undesirable security implications. It moves the exception table out of the read-only mappings into the read-write mappings, thereby providing a way for an attacker to bypass the read-only protection on the kernel and manipulate code pointers at potentially known addresses for distro built kernels. > I agree there is a risk but I don't think it's high. It does not look like > the minor changes in "reserved" reporting in /proc/iomem will break kexec > tooling. What makes you come to that conclusion? The kexec tools architecture backends get to decide what they do when parsing /proc/iomem. Currently, only firmware areas are marked reserved in /proc/iomem on 32-bit ARM. This is read by kexec, and entered into its memory_range[] table as either RAM, or RESERVED. kexec uses this to search for a suitable hole in the memory map to place the kernel in physical memory. The addition of what I will call ficticious "reserved" areas by the host kernel because the host kernel happened to use them _will_ have an impact on this. They _are_ ficticious, because they are purely an artifact of the host kernel being run, and are of no consequence to tooling such as kexec. What such tooling is interested in is which areas it needs to avoid because of firmware. I think what isn't helping here is that you haven't adequately described what your overall objective actually is. Framing it in terms of wanting the reserved memory to be consistent between the various kernel "interfaces" such as /proc/iomem, the memblock debugfs and firmware is very ambiguous and open to different interpretations, whcih I think is what the problem is here. > Anyway the amount of reserved and free memory depends on a > particular system, kernel version, configuration and command line. > I have no intention to report kernel boot time reservations > to /proc/iomem on architectures that do not report them there today, > although this also does not seem like a significant factor. You seem to be missing the point I've tried to make. The areas in memblock that are marked "reserved" are the areas of reserved memory from the firmware _plus_ the areas that the kernel has made during boot which are of no consequence to userspace. Wanting /proc/iomem, memblock and firmware to all agree on the values that they mark as "reserved" is IMHO unrealistic. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel