public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v31 05/12] arm64: kdump: protect crash dump kernel memory
Date: Thu, 2 Feb 2017 15:36:13 +0000	[thread overview]
Message-ID: <20170202153612.GN31394@leverpostej> (raw)
In-Reply-To: <20170202143602.GA3078@fireball>

On Thu, Feb 02, 2017 at 11:36:04PM +0900, AKASHI Takahiro wrote:
> On Thu, Feb 02, 2017 at 11:16:37AM +0000, Mark Rutland wrote:
> > On Thu, Feb 02, 2017 at 07:31:30PM +0900, AKASHI Takahiro wrote:
> > > On Wed, Feb 01, 2017 at 06:00:08PM +0000, Mark Rutland wrote:
> > > > On Wed, Feb 01, 2017 at 09:46:24PM +0900, AKASHI Takahiro wrote:

> > Imagine we have phyiscal memory:
> > 
> > singe RAM bank:    |---------------------------------------------------|
> > kernel image:              |---|
> > crashkernel:                                      |------|
> > 
> > ... we reserve the image and crashkernel region, but these would still
> > remain part of the memory memblock, and we'd have a memblock layout
> > like:
> > 
> > memblock.memory:   |---------------------------------------------------|
> > memblock.reserved:         |---|                  |------|
> > 
> > ... in map_mem() we iterate over memblock.memory, so we only have a
> > single entry to handle in this case. With the code above, we'd find that
> > it overlaps the crashk_res, and we'd map the parts which don't overlap,
> > e.g.
> > 
> > memblock.memory:   |---------------------------------------------------|
> > crashkernel:                                      |------|
> > mapped regions:    |-----------------------------|        |------------|
> 
> I'm afraid that you might be talking about my v30.
> The code in v31 was a bit modified, and now
> 
> > ... hwoever, this means we've mapped the portion which overlaps with the
> > kernel's linear alias (i.e. the case that we try to handle in
> > __map_memblock()). What we actually wanted was:
> > 
> > memblock.memory:   |---------------------------------------------------|
> > kernel image:              |---|
> > crashkernel:                                      |------|
> 
>                      |-----------(A)---------------|        |----(B)-----|
> 
> __map_memblock() is called against each of (A) and (B),
> so I think we will get
> 
> > mapped regions:    |------|     |----------------|        |------------|
> 
> this mapping.

Ah, I see. You are correct; this will work.

Clearly I needed more coffee before considering this. :/

> > To handle all cases I think we have to isolate *both* the image and
> > crashkernel in map_mem(). That would leave use with:
> > 
> > memblock.memory:   |------||---||----------------||------||------------|
> > memblock.reserved:         |---|                  |------|
> > 
> > ... so then we can check for overlap with either the kernel or
> > crashkernel in __map_memblock(), and return early, e.g.
> > 
> > __map_memblock(...)
> > 	if (overlaps_with_kernel(...))
> > 		return;
> > 	if (overlaps_with_crashekrenl(...))
> > 		return;
> > 	
> > 	__create_pgd_mapping(...);
> > }
> > 
> > We can pull the kernel alias mapping out of __map_memblock() and put it
> > at the end of map_mem().
> > 
> > Does that make sense?
> 
> OK, I now understand your anticipation.

Thinking about it, we can do this consistently in one place if we use nomap
(temporarily), which would allow us to simplify the existing code. We'd have to
introduce memblock_clear_nomap(), but that's less of an internal detail than
memblock_isolate_range(), so that seems reasonable.

I think we can handle this like:

/*
 * Create a linear mapping for all memblock memory regions which are mappable.
 */
static void __init __map_mem(pgd_t *pgd)
{
        struct memblock_region *reg;

        /* map all the memory banks */
        for_each_memblock(memory, reg) {
                phys_addr_t start = reg->base;
                phys_addr_t end = start + reg->size;

                if (start >= end)
                        break;
                if (memblock_is_nomap(reg))
                        continue;

                __create_pgd_mapping(pgd, start, __phys_to_virt(start),
                                     end - start, PAGE_KERNEL,
                                     early_pgtable_alloc,
                                     debug_pagealloc_enabled());
        }   
}

/*
 * Create a linear mapping for mappable memory, handling regions which have
 * special mapping requirements.
 */
static void __init map_mem(pgd_t *pgd)
{
        unsigned long kernel_start = __pa(_text);
        unsigned long kernel_end = __pa(__init_begin);

        memblock_mark_nomap(kernel_start, kernel_end);

        // mark crashkernel nomap here

        __map_mem(pgd);

        /*  
         * Map the linear alias of the [_text, __init_begin) interval as
         * read-only/non-executable. This makes the contents of the
         * region accessible to subsystems such as hibernate, but
         * protects it from inadvertent modification or execution.
         */
        __create_pgd_mapping(pgd, kernel_start, __phys_to_virt(kernel_start),
                             kernel_end - kernel_start, PAGE_KERNEL_RO,
                             early_pgtable_alloc, debug_pagealloc_enabled());
        memblock_clear_nomap(kernel_start, kernel_end);

        // map crashkernel here
        // clear nomap for crashkernel
}

Thoughts?

Thanks,
Mark.

  reply	other threads:[~2017-02-02 15:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-01 12:42 [PATCH v31 00/12] add kdump support AKASHI Takahiro
2017-02-01 12:45 ` [PATCH v31 01/12] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 02/12] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2017-02-01 15:07   ` Mark Rutland
2017-02-02  4:21     ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 03/12] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2017-02-01 15:26   ` Mark Rutland
2017-02-02  4:52     ` AKASHI Takahiro
2017-02-02 11:26       ` Mark Rutland
2017-02-02 13:44         ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 04/12] arm64: mm: allow for unmapping part of kernel mapping AKASHI Takahiro
2017-02-01 16:03   ` Mark Rutland
2017-02-02 10:21     ` AKASHI Takahiro
2017-02-02 11:44       ` Mark Rutland
2017-02-02 14:01         ` AKASHI Takahiro
2017-02-02 14:35           ` Mark Rutland
2017-02-02 14:55             ` AKASHI Takahiro
2017-02-03  6:13               ` AKASHI Takahiro
2017-02-03 14:22                 ` Mark Rutland
2017-02-01 12:46 ` [PATCH v31 05/12] arm64: kdump: protect crash dump kernel memory AKASHI Takahiro
2017-02-01 18:00   ` Mark Rutland
2017-02-01 18:25     ` Mark Rutland
2017-02-02 10:39       ` AKASHI Takahiro
2017-02-02 11:54         ` Mark Rutland
2017-02-03  1:45           ` AKASHI Takahiro
2017-02-03 11:51             ` Mark Rutland
2017-02-02 10:45       ` James Morse
2017-02-02 11:19         ` AKASHI Takahiro
2017-02-02 11:48         ` Mark Rutland
2017-02-02 10:31     ` AKASHI Takahiro
2017-02-02 11:16       ` Mark Rutland
2017-02-02 14:36         ` AKASHI Takahiro
2017-02-02 15:36           ` Mark Rutland [this message]
2017-02-01 12:46 ` [PATCH v31 06/12] arm64: hibernate: preserve kdump image around hibernation AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 07/12] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 08/12] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 09/12] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2017-02-01 19:21   ` Mark Rutland
2017-02-02  6:24     ` AKASHI Takahiro
2017-02-02 12:03       ` Mark Rutland
2017-02-02 12:08         ` Mark Rutland
2017-02-02 14:39           ` AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 10/12] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2017-02-01 12:46 ` [PATCH v31 11/12] Documentation: kdump: describe arm64 port AKASHI Takahiro
2017-02-01 12:48 ` [PATCH v31 12/12] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro

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=20170202153612.GN31394@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox