From: =?UTF-8?B?InRpcC1ib3QgZm9yIEJyeWFuIE8nRG9ub2dodWUiIDx0aXBib3RAenl0b3IuY28=?=.=?UTF-8?B?bT4=?=@zytor.com
To: =?UTF-8?B?bGludXgtdGlwLWNvbW1pdHNAdmdlci5rZXJuZWwub3Jn?=@zytor.com
Cc: torvalds@linux-foundation.org, andriy.shevchenko@linux.intel.com,
mingo@kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, peterz@infradead.org, hpa@zytor.com,
pure.logic@nexus-software.ie
Subject: [tip:x86/platform] x86/platform/intel/quark: Change the kernel's IMR lock bit to false
Date: Tue, 23 Feb 2016 00:54:40 -0800 [thread overview]
Message-ID: <tip-dd71a17b1193dd4a4c35ecd0ba227aac3d110836@git.kernel.org> (raw)
In-Reply-To: <1456190999-12685-2-git-send-email-pure.logic@nexus-software.ie>
Commit-ID: dd71a17b1193dd4a4c35ecd0ba227aac3d110836
Gitweb: http://git.kernel.org/tip/dd71a17b1193dd4a4c35ecd0ba227aac3d110836
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
AuthorDate: Tue, 23 Feb 2016 01:29:58 +0000
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Tue, 23 Feb 2016 07:35:53 +0100
x86/platform/intel/quark: Change the kernel's IMR lock bit to false
Currently when setting up an IMR around the kernel's .text section we lock
that IMR, preventing further modification. While superficially this appears
to be the right thing to do, in fact this doesn't account for a legitimate
change in the memory map such as when executing a new kernel via kexec.
In such a scenario a second kernel can have a different size and location
to it's predecessor and can view some of the memory occupied by it's
predecessor as legitimately usable DMA RAM. If this RAM were then
subsequently allocated to DMA agents within the system it could conceivably
trigger an IMR violation.
This patch fixes the this potential situation by keeping the kernel's .text
section IMR lock bit false by default.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boon.leong.ong@intel.com
Cc: paul.gortmaker@windriver.com
Link: http://lkml.kernel.org/r/1456190999-12685-2-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/platform/intel-quark/imr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/platform/intel-quark/imr.c b/arch/x86/platform/intel-quark/imr.c
index c61b6c3..bfadcd0 100644
--- a/arch/x86/platform/intel-quark/imr.c
+++ b/arch/x86/platform/intel-quark/imr.c
@@ -592,14 +592,14 @@ static void __init imr_fixup_memmap(struct imr_device *idev)
end = (unsigned long)__end_rodata - 1;
/*
- * Setup a locked IMR around the physical extent of the kernel
+ * Setup an unlocked IMR around the physical extent of the kernel
* from the beginning of the .text secton to the end of the
* .rodata section as one physically contiguous block.
*
* We don't round up @size since it is already PAGE_SIZE aligned.
* See vmlinux.lds.S for details.
*/
- ret = imr_add_range(base, size, IMR_CPU, IMR_CPU, true);
+ ret = imr_add_range(base, size, IMR_CPU, IMR_CPU, false);
if (ret < 0) {
pr_err("unable to setup IMR for kernel: %zu KiB (%lx - %lx)\n",
size / 1024, start, end);
next prev parent reply other threads:[~2016-02-23 9:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 1:29 [PATCH v3 0/2] x86/intel/imr: Fix IMR lock logic Bryan O'Donoghue
2016-02-23 1:29 ` [PATCH v3 1/2] x86/intel/imr: Change the kernel's IMR lock bit to false Bryan O'Donoghue
2016-02-23 8:54 ` =?UTF-8?B?InRpcC1ib3QgZm9yIEJyeWFuIE8nRG9ub2dodWUiIDx0aXBib3RAenl0b3IuY28=?=.=?UTF-8?B?bT4=?= [this message]
2016-02-23 9:26 ` [tip:x86/platform] x86/platform/intel/quark: " Peter Zijlstra
2016-02-23 10:12 ` Ingo Molnar
2016-02-23 1:29 ` [PATCH v3 2/2] x86/intel/imr: Drop IMR lock bit support Bryan O'Donoghue
2016-02-23 8:55 ` [tip:x86/platform] x86/platform/intel/quark: " =?UTF-8?B?InRpcC1ib3QgZm9yIEJyeWFuIE8nRG9ub2dodWUiIDx0aXBib3RAenl0b3IuY28=?=.=?UTF-8?B?bT4=?=
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=tip-dd71a17b1193dd4a4c35ecd0ba227aac3d110836@git.kernel.org \
--to==?utf-8?b?inrpcc1ib3qgzm9yiejyewfuie8nrg9ub2dodwuiidx0axbib3raenl0b3iuy28=?=.=?utf-8?b?bt4=?=@zytor.com \
--cc==?UTF-8?B?bGludXgtdGlwLWNvbW1pdHNAdmdlci5rZXJuZWwub3Jn?=@zytor.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=pure.logic@nexus-software.ie \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.