All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Morse <james.morse@arm.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: mark.rutland@arm.com, geoff@infradead.org,
	catalin.marinas@arm.com, will.deacon@arm.com,
	bauerman@linux.vnet.ibm.com, dyoung@redhat.com,
	kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v32 06/13] arm64: kdump: protect crash dump kernel memory
Date: Fri, 17 Feb 2017 16:08:44 +0000	[thread overview]
Message-ID: <58A7200C.8010707@arm.com> (raw)
In-Reply-To: <20170207080904.5974-4-takahiro.akashi@linaro.org>

Hi Akashi,

On 07/02/17 08:08, AKASHI Takahiro wrote:
> arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres()
> are meant to be called by kexec_load() in order to protect the memory
> allocated for crash dump kernel once it's loaded.
> 
> Here, the protection is implemented by unmapping the relevant range
> of memory, rather than making it read-only, to prevent any corruption
> due to potential cache alias (with different attributes) problem.
> 
> To make the things work correctly, we have to
> - use page-level mappings entirely
> - have the mappings isolated from the other normal memory
> - move copying kexec's control_code_page to machine_kexec_prepare()
> 
> Note that page-level mappings are required to allow shrinking the region,
> through /sys/kernel/kexec_crash_size, to the size of any number of pages
> and putting the freed memory back to buddy system.

This shrinking means memory marked memblock:reserve gets used by the slab
allocator. This makes me feel uneasy, but I agree its not going to break
anything, and we can't easily un-reserve it.

The temporary no-map when building the linear map is a neat trick!

Reviewed-by: James Morse <james.morse@arm.com>


This patch will conflict with Ard's 'arm64: mmu: avoid writeable-executable
mappings' series[0], but they may be complimentary as he adds a
update_mapping_prot() call in patch 2 [1] which has a similar use-case.


Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg562724.html
[1] https://www.spinics.net/lists/arm-kernel/msg562726.html

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v32 06/13] arm64: kdump: protect crash dump kernel memory
Date: Fri, 17 Feb 2017 16:08:44 +0000	[thread overview]
Message-ID: <58A7200C.8010707@arm.com> (raw)
In-Reply-To: <20170207080904.5974-4-takahiro.akashi@linaro.org>

Hi Akashi,

On 07/02/17 08:08, AKASHI Takahiro wrote:
> arch_kexec_protect_crashkres() and arch_kexec_unprotect_crashkres()
> are meant to be called by kexec_load() in order to protect the memory
> allocated for crash dump kernel once it's loaded.
> 
> Here, the protection is implemented by unmapping the relevant range
> of memory, rather than making it read-only, to prevent any corruption
> due to potential cache alias (with different attributes) problem.
> 
> To make the things work correctly, we have to
> - use page-level mappings entirely
> - have the mappings isolated from the other normal memory
> - move copying kexec's control_code_page to machine_kexec_prepare()
> 
> Note that page-level mappings are required to allow shrinking the region,
> through /sys/kernel/kexec_crash_size, to the size of any number of pages
> and putting the freed memory back to buddy system.

This shrinking means memory marked memblock:reserve gets used by the slab
allocator. This makes me feel uneasy, but I agree its not going to break
anything, and we can't easily un-reserve it.

The temporary no-map when building the linear map is a neat trick!

Reviewed-by: James Morse <james.morse@arm.com>


This patch will conflict with Ard's 'arm64: mmu: avoid writeable-executable
mappings' series[0], but they may be complimentary as he adds a
update_mapping_prot() call in patch 2 [1] which has a similar use-case.


Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg562724.html
[1] https://www.spinics.net/lists/arm-kernel/msg562726.html

  reply	other threads:[~2017-02-17 16:08 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07  8:06 [PATCH v32 00/13] arm64: add kdump support AKASHI Takahiro
2017-02-07  8:06 ` AKASHI Takahiro
2017-02-07  8:08 ` [PATCH v32 01/13] memblock: add memblock_clear_nomap() AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08 ` [PATCH v32 02/13] memblock: add memblock_cap_memory_range() AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08 ` [PATCH v32 03/13] arm64: limit memory regions based on DT property, usable-memory-range AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08 ` [PATCH v32 04/13] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08 ` [PATCH v32 05/13] arm64: mm: allow for unmapping part of kernel mapping AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-07  8:08 ` [PATCH v32 06/13] arm64: kdump: protect crash dump kernel memory AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-17 16:08   ` James Morse [this message]
2017-02-17 16:08     ` James Morse
2017-02-07  8:08 ` [PATCH v32 07/13] arm64: hibernate: preserve kdump image around hibernation AKASHI Takahiro
2017-02-07  8:08   ` AKASHI Takahiro
2017-02-15 12:12   ` James Morse
2017-02-15 12:12     ` James Morse
2017-02-16  9:52     ` AKASHI Takahiro
2017-02-16  9:52       ` AKASHI Takahiro
2017-02-07  8:09 ` [PATCH v32 08/13] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2017-02-07  8:09   ` AKASHI Takahiro
2017-02-07  8:09 ` [PATCH v32 09/13] arm64: kdump: add VMCOREINFO's for user-space tools AKASHI Takahiro
2017-02-07  8:09   ` AKASHI Takahiro
2017-02-07  8:09 ` [PATCH v32 10/13] arm64: kdump: provide /proc/vmcore file AKASHI Takahiro
2017-02-07  8:09   ` AKASHI Takahiro
2017-02-07  8:09 ` [PATCH v32 11/13] arm64: kdump: enable kdump in defconfig AKASHI Takahiro
2017-02-07  8:09   ` AKASHI Takahiro
2017-02-07  8:09 ` [PATCH v32 12/13] Documentation: kdump: describe arm64 port AKASHI Takahiro
2017-02-07  8:09   ` AKASHI Takahiro
2017-02-07  8:10 ` [PATCH v32 13/13] Documentation: dt: chosen properties for arm64 kdump AKASHI Takahiro
2017-02-07  8:10   ` AKASHI Takahiro
2017-02-07  8:10   ` AKASHI Takahiro
2017-02-08  5:39 ` [PATCH v32 00/13] arm64: add kdump support Pratyush Anand
2017-02-08  5:39   ` Pratyush Anand
2017-03-02  0:51 ` Goel, Sameer
2017-03-02  0:51   ` Goel, Sameer
2017-03-02 10:34   ` AKASHI Takahiro
2017-03-02 10:34     ` 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=58A7200C.8010707@arm.com \
    --to=james.morse@arm.com \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=catalin.marinas@arm.com \
    --cc=dyoung@redhat.com \
    --cc=geoff@infradead.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=takahiro.akashi@linaro.org \
    --cc=will.deacon@arm.com \
    /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.