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 8E1EAC47096 for ; Thu, 3 Jun 2021 10:32:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 39C63613B4 for ; Thu, 3 Jun 2021 10:32:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39C63613B4 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 6F5E96B0078; Thu, 3 Jun 2021 06:32:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CC916B007B; Thu, 3 Jun 2021 06:32:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 51F9C6B007D; Thu, 3 Jun 2021 06:32:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id 1B17F6B0078 for ; Thu, 3 Jun 2021 06:32:22 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A4FACC5DE for ; Thu, 3 Jun 2021 10:32:21 +0000 (UTC) X-FDA: 78212048082.08.3E4CE58 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP id 8A7354202A29 for ; Thu, 3 Jun 2021 10:32:11 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id D65BC613B4; Thu, 3 Jun 2021 10:32:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1622716340; bh=X5aLnubKAmnjv11r/M1yhgLc/kSlye6ydJVcueRcSJM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZFiJY4nZsZfw97zIHkBEr3VpNpMUKzlrhETGTbuErOKNsf/bLe+LuyXJXk5EACpKK MZUE7KzGUgKgwe1GiaI40o1kN29hxhkKEknugf+NAqPxGx0S8+0A0QtDAfqTSXBhzZ NVDQIJ2oxYkEBkpO4ZhWhSCNg8wsqUOTT3HRj9PLSbeS5jWRqRKQlVtSISMVZEPsZB CRaspjduFgAQG0PguB9XyA+3cHreOeMFv9tpLn/bnY4YmfgWn/LS6ExOdkYlu4qguU BxSMpkXsv1XZVLcRvR02mvIlfd8BTTGdNmP1ZPmeSV7m5fVMo3pe/F5W157wYxYtti L6n25V+hCu22A== Date: Thu, 3 Jun 2021 13:32:11 +0300 From: Mike Rapoport To: "Russell King (Oracle)" 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: 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> <20210602201502.GP30436@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210602201502.GP30436@shell.armlinux.org.uk> Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZFiJY4nZ; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf17.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 8A7354202A29 X-Stat-Signature: j3bgxsuk17g5hckfsmb6boksozp4wjfh X-HE-Tag: 1622716331-859235 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 Wed, Jun 02, 2021 at 09:15:02PM +0100, Russell King (Oracle) wrote: > 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: > > > 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. My point was that __ex_table can be in "Kernel data" or "Kernel rodata" without loosing the ability to sort it. > 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. I know what areas are marked "reserved" in memblock. I never suggested to report "ficticious" reserved areas in /proc/iomem unless an architecture already reports them there, like arm64 for example. You are right I should have described better the overall objective, but sill I feel that we keep missing each other points. I'll update the descriptions for the next repost, hopefully it'll help. -- Sincerely yours, Mike.