From: Borislav Petkov <bp@suse.de>
To: "H. Peter Anvin" <hpa@zytor.com>,
Kees Cook <keescook@chromium.org>, Jiri Kosina <jkosina@suse.cz>
Cc: Ingo Molnar <mingo@kernel.org>, Huang Ying <ying.huang@intel.com>,
Jiri Kosina <jkosina@suse.cz>,
LKML <linux-kernel@vger.kernel.org>, LKP ML <lkp@01.org>,
x86-ml <x86@kernel.org>, Dave Young <dyoung@redhat.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [LKP] [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0()
Date: Sat, 28 Feb 2015 11:50:49 +0100 [thread overview]
Message-ID: <20150228105049.GA11038@pd.tnic> (raw)
In-Reply-To: <20150226121617.GB3573@pd.tnic>
On Thu, Feb 26, 2015 at 01:16:17PM +0100, Borislav Petkov wrote:
> The proper fix should be to say, don't ioremap setup_data which is
> kernel memory but I'm not sure I have a good idea at the moment how to
> do that *without* ioremapping the thing to inspect it first...
>
> More hmm...
Yeah, too many hmms means this still needed staring at to find out what
exactly the problem is. And the problem is that allocating that struct
setup_data statically in arch/x86/boot/compressed/aslr.c works only by
chance, when the kernel decompressing doesn't overwrite that memory.
One thing that we could do is to stick it right below LOAD_PHYSICAL_ADDR
(16M by default) which is the miminum physical address for the kernel to
be loaded at and kaslr pays attention to.
I.e., this struct setup_data thing lands then here:
[ 0.000000] parse_setup_data: data: 0xffffe0 (va: ffffffffff200fe0) { next: 0x0, type: 0x5, len: 17, data[0]: 0x0 }
which is 16M - 2*sizeof(struct setup_data). Yeah, I left some room
there.
Now, this approach works but I'm not sure whether this is how we want to
be passing setup_data stuff from arch/x86/boot/ to kernel proper so I'd
like to hear some more experienced opinions please...
Thanks!
---
diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
index 7083c16cccba..9f64c64e3ebe 100644
--- a/arch/x86/boot/compressed/aslr.c
+++ b/arch/x86/boot/compressed/aslr.c
@@ -14,12 +14,7 @@
static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
-struct kaslr_setup_data {
- __u64 next;
- __u32 type;
- __u32 len;
- __u8 data[1];
-} kaslr_setup_data;
+struct setup_data *ksd;
#define I8254_PORT_CONTROL 0x43
#define I8254_PORT_COUNTER0 0x40
@@ -302,14 +297,20 @@ static unsigned long find_random_addr(unsigned long minimum,
return slots_fetch_random();
}
-static void add_kaslr_setup_data(struct boot_params *params, __u8 enabled)
+static void add_kaslr_setup_data(struct boot_params *params,
+ u8 *output, __u8 enabled)
{
struct setup_data *data;
- kaslr_setup_data.type = SETUP_KASLR;
- kaslr_setup_data.len = 1;
- kaslr_setup_data.next = 0;
- kaslr_setup_data.data[0] = enabled;
+ /*
+ * Stick it right under LOAD_PHYSICAL_ADDR
+ */
+ ksd = (struct setup_data *)(output - 2 * sizeof(struct setup_data));
+
+ ksd->type = SETUP_KASLR;
+ ksd->len = 1;
+ ksd->next = 0;
+ ksd->data[0] = enabled;
data = (struct setup_data *)(unsigned long)params->hdr.setup_data;
@@ -317,10 +318,9 @@ static void add_kaslr_setup_data(struct boot_params *params, __u8 enabled)
data = (struct setup_data *)(unsigned long)data->next;
if (data)
- data->next = (unsigned long)&kaslr_setup_data;
+ data->next = (unsigned long)ksd;
else
- params->hdr.setup_data = (unsigned long)&kaslr_setup_data;
-
+ params->hdr.setup_data = (unsigned long)ksd;
}
unsigned char *choose_kernel_location(struct boot_params *params,
@@ -335,17 +335,17 @@ unsigned char *choose_kernel_location(struct boot_params *params,
#ifdef CONFIG_HIBERNATION
if (!cmdline_find_option_bool("kaslr")) {
debug_putstr("KASLR disabled by default...\n");
- add_kaslr_setup_data(params, 0);
+ add_kaslr_setup_data(params, output, 0);
goto out;
}
#else
if (cmdline_find_option_bool("nokaslr")) {
debug_putstr("KASLR disabled by cmdline...\n");
- add_kaslr_setup_data(params, 0);
+ add_kaslr_setup_data(params, output, 0);
goto out;
}
#endif
- add_kaslr_setup_data(params, 1);
+ add_kaslr_setup_data(params, output, 1);
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigned long)input, input_size,
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 98dc9317286e..d3b34df6e539 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -429,7 +429,11 @@ static void __init reserve_initrd(void)
static void __init parse_kaslr_setup(u64 pa_data, u32 data_len)
{
- kaslr_enabled = (bool)(pa_data + sizeof(struct setup_data));
+ struct setup_data *kdata;
+
+ kdata = early_memremap(pa_data, data_len);
+ kaslr_enabled = kdata->data[0];
+ early_iounmap(kdata, data_len);
}
static void __init parse_setup_data(void)
---
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
next prev parent reply other threads:[~2015-02-28 10:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 5:37 [LKP] [x86/mm/ASLR] f47233c2d34: WARNING: CPU: 0 PID: 1 at arch/x86/mm/ioremap.c:63 __ioremap_check_ram+0x445/0x4a0() Huang Ying
2015-02-26 10:30 ` Borislav Petkov
2015-02-26 11:12 ` Ingo Molnar
2015-02-26 12:16 ` Borislav Petkov
2015-02-28 10:50 ` Borislav Petkov [this message]
2015-02-28 19:20 ` Matt Fleming
2015-02-28 19:52 ` Borislav Petkov
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=20150228105049.GA11038@pd.tnic \
--to=bp@suse.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=luto@amacapital.net \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=x86@kernel.org \
--cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox