All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Mike Rapoport <rppt@linux.ibm.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Vasily Gorbik <gor@linux.ibm.com>, Will Deacon <will@kernel.org>,
	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()
Date: Thu, 3 Jun 2021 13:32:11 +0300	[thread overview]
Message-ID: <YLivq1QRcStvpsLr@kernel.org> (raw)
In-Reply-To: <20210602201502.GP30436@shell.armlinux.org.uk>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Mike Rapoport <rppt@linux.ibm.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	Heiko Carstens <hca@linux.ibm.com>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Vasily Gorbik <gor@linux.ibm.com>, Will Deacon <will@kernel.org>,
	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()
Date: Thu, 3 Jun 2021 13:32:11 +0300	[thread overview]
Message-ID: <YLivq1QRcStvpsLr@kernel.org> (raw)
In-Reply-To: <20210602201502.GP30436@shell.armlinux.org.uk>

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-03 10:32 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-31 12:29 [RFC/RFT PATCH 0/5] consolidate "System RAM" resources setup Mike Rapoport
2021-05-31 12:29 ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 1/5] s390: make crashk_res resource a child of "System RAM" Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-06-01  8:45   ` David Hildenbrand
2021-06-01  8:45     ` David Hildenbrand
2021-06-01  9:02     ` David Hildenbrand
2021-06-01  9:02       ` David Hildenbrand
2021-06-02  6:25       ` Mike Rapoport
2021-06-02  6:25         ` Mike Rapoport
2021-06-01 13:18   ` Gerald Schaefer
2021-06-01 13:18     ` Gerald Schaefer
2021-06-02  6:54     ` Mike Rapoport
2021-06-02  6:54       ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 2/5] memblock: introduce generic memblock_setup_resources() Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-06-01 13:54   ` Russell King (Oracle)
2021-06-01 13:54     ` Russell King (Oracle)
2021-06-02  8:33     ` Mike Rapoport
2021-06-02  8:33       ` Mike Rapoport
2021-06-02 10:15       ` Russell King (Oracle)
2021-06-02 10:15         ` Russell King (Oracle)
2021-06-02 13:54         ` Mike Rapoport
2021-06-02 13:54           ` Mike Rapoport
2021-06-02 15:51           ` Russell King (Oracle)
2021-06-02 15:51             ` Russell King (Oracle)
2021-06-02 18:43             ` Mike Rapoport
2021-06-02 18:43               ` Mike Rapoport
2021-06-02 20:15               ` Russell King (Oracle)
2021-06-02 20:15                 ` Russell King (Oracle)
2021-06-03 10:32                 ` Mike Rapoport [this message]
2021-06-03 10:32                   ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 3/5] arm: switch to " Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 4/5] MIPS: switch to generic memblock_setup_resources Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-05-31 12:29 ` [RFC/RFT PATCH 5/5] arm64: switch to generic memblock_setup_resources() Mike Rapoport
2021-05-31 12:29   ` Mike Rapoport
2021-06-01 13:44 ` [RFC/RFT PATCH 0/5] consolidate "System RAM" resources setup Russell King (Oracle)
2021-06-01 13:44   ` Russell King (Oracle)
2021-06-02  7:05   ` Mike Rapoport
2021-06-02  7:05     ` Mike Rapoport
  -- strict thread matches above, loose matches on Subject: below --
2021-06-01  1:39 [RFC/RFT PATCH 2/5] memblock: introduce generic memblock_setup_resources() kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YLivq1QRcStvpsLr@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=borntraeger@de.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=rppt@linux.ibm.com \
    --cc=tsbogend@alpha.franken.de \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.