From: Dan Rosenberg <drosenberg@vsecurity.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>, Tony Luck <tony.luck@gmail.com>,
linux-kernel@vger.kernel.org, davej@redhat.com,
kees.cook@canonical.com, davem@davemloft.net, eranian@google.com,
torvalds@linux-foundation.org, adobriyan@gmail.com,
penberg@kernel.org, Arjan van de Ven <arjan@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Valdis.Kletnieks@vt.edu, pageexec@freemail.hu
Subject: Re: [RFC][PATCH] Randomize kernel base address on boot
Date: Wed, 25 May 2011 12:15:41 -0400 [thread overview]
Message-ID: <1306340141.2211.32.camel@dan> (raw)
In-Reply-To: <4DDD24E2.4010602@zytor.com>
On Wed, 2011-05-25 at 08:48 -0700, H. Peter Anvin wrote:
> On 05/25/2011 07:03 AM, Dan Rosenberg wrote:
> >
> > My current idea is to use int 0x15, eax = 0xe801 (which seems to be
> > nearly universally supported) and use bx/dx to determine the amount of
> > contiguous, usable memory above 16 MB, which seems to be exactly what we
> > want to know. If the BIOS does not support this function I'll be sure
> > to catch that and skip the randomization. Likewise, if the amount of
> > returned memory seems insufficient or otherwise confusing, I'll skip the
> > randomization.
> >
>
> No, sorry. This has been wrong for over 10 years; there is no
> substitute for the full (e820) memory map. *Furthermore*, based on
> where in the bootup sequence you are doing this, you also have to
> consider any other memory structures that the kernel needs to be aware
> of (initramfs, any chunks in the linked list, the command line, EFI
> handover structures, etc.) This is in fact an arbitrarily complex
> operation... we have *finally* gotten the kernel to the point where (a)
> the boot loader can actually do the right thing in all cases and (b) the
> kernel will reserve or copy all the auxiliary memory chunks it needs at
> a very early point.
>
> Sorry, this cannot be short-circuited.
>
Ok, checking the e820 memory map seems like the way to go then. As a
first attempt, I'd assume that if I find a contiguous free chunk that
begins before (or at) 16 MB and continues beyond 16 MB, then that
represents space where it's safe to load the kernel (up to a certain
point before the end of that chunk), assuming the chunk has enough space
and I do some degree of checking that I'm not decompressing on top of
something else (I'll start to gather a list of what to watch out for).
Is this a fair assumption?
> > Given this information, do you have a conservative guess for how close
> > to the top of available memory we can put the kernel? As in, let's say
> > we have an XYZ MB chunk of contiguous, free memory, how should I
> > calculate the highest, safe place to put the kernel in that region?
> >
> > I'm going to continue to enforce the requirement that 16 MB is the
> > lowest address we can safely load the kernel, and I'd still appreciate
> > any information on why 2/4 MB default alignment might cause problems.
>
> The problem with all of that was backwards compatibility with existing
> relocating bootloaders.
>
Do you have any alternatives that allow maintaining compatibility while
giving us finer-grained alignment? It seems it should be possible,
since alignment was lower than 16 MB for years before this change was
introduced...
Thanks,
Dan
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2011-05-25 16:15 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 20:31 [RFC][PATCH] Randomize kernel base address on boot Dan Rosenberg
2011-05-24 21:02 ` Ingo Molnar
2011-05-24 22:55 ` Dan Rosenberg
2011-05-24 21:16 ` Ingo Molnar
2011-05-24 23:00 ` Dan Rosenberg
2011-05-25 11:23 ` Ingo Molnar
2011-05-25 14:20 ` Dan Rosenberg
2011-05-25 14:29 ` Ingo Molnar
2011-05-24 23:06 ` H. Peter Anvin
2011-05-25 14:03 ` Dan Rosenberg
2011-05-25 14:14 ` Ingo Molnar
2011-05-25 15:48 ` H. Peter Anvin
2011-05-25 16:15 ` Dan Rosenberg [this message]
2011-05-25 16:24 ` H. Peter Anvin
2011-05-24 21:46 ` Brian Gerst
2011-05-24 23:01 ` Dan Rosenberg
2011-05-24 22:31 ` H. Peter Anvin
2011-05-24 23:04 ` Dan Rosenberg
2011-05-24 23:07 ` H. Peter Anvin
2011-05-24 23:34 ` Dan Rosenberg
2011-05-24 23:36 ` H. Peter Anvin
2011-05-24 23:14 ` H. Peter Anvin
2011-05-24 23:08 ` Dan Rosenberg
2011-05-25 2:05 ` Dan Rosenberg
2011-05-26 20:01 ` Vivek Goyal
2011-05-26 20:06 ` Dan Rosenberg
2011-05-26 20:16 ` Valdis.Kletnieks
2011-05-26 20:31 ` Vivek Goyal
2011-05-27 9:36 ` Ingo Molnar
2011-05-26 20:35 ` Vivek Goyal
2011-05-26 20:40 ` Vivek Goyal
2011-05-26 20:44 ` Dan Rosenberg
2011-05-26 20:55 ` Vivek Goyal
2011-05-27 9:38 ` Ingo Molnar
2011-05-27 13:07 ` Vivek Goyal
2011-05-27 13:38 ` Ingo Molnar
2011-05-27 13:13 ` Vivek Goyal
2011-05-27 13:21 ` Dan Rosenberg
2011-05-27 13:46 ` Ingo Molnar
2011-05-27 13:50 ` Vivek Goyal
2011-05-26 20:39 ` Dan Rosenberg
2011-05-27 7:15 ` Ingo Molnar
2011-05-31 16:52 ` Matthew Garrett
2011-05-31 18:40 ` H. Peter Anvin
2011-05-31 18:51 ` Matthew Garrett
2011-05-31 19:03 ` Dan Rosenberg
2011-05-31 19:07 ` H. Peter Anvin
2011-05-31 19:50 ` Ingo Molnar
2011-05-31 19:55 ` Ingo Molnar
2011-05-31 20:15 ` H. Peter Anvin
2011-05-31 20:27 ` Ingo Molnar
2011-05-31 20:30 ` H. Peter Anvin
2011-06-01 6:18 ` Ingo Molnar
2011-06-01 15:44 ` H. Peter Anvin
2011-05-31 20:17 ` Dan Rosenberg
2011-05-26 22:18 ` Rafael J. Wysocki
2011-05-26 22:32 ` H. Peter Anvin
2011-05-27 0:26 ` Dan Rosenberg
2011-05-27 16:21 ` Rafael J. Wysocki
2011-05-27 2:45 ` Dave Jones
2011-05-27 9:40 ` Ingo Molnar
2011-05-27 16:11 ` Rafael J. Wysocki
2011-05-27 16:07 ` Rafael J. Wysocki
2011-05-27 15:42 ` Linus Torvalds
2011-05-27 16:11 ` Dan Rosenberg
2011-05-27 17:00 ` Ingo Molnar
2011-05-27 17:06 ` H. Peter Anvin
2011-05-27 17:10 ` Dan Rosenberg
2011-05-27 17:13 ` H. Peter Anvin
2011-05-27 17:16 ` Linus Torvalds
2011-05-27 17:38 ` Ingo Molnar
2011-05-27 17:20 ` Kees Cook
2011-05-27 17:16 ` Ingo Molnar
2011-05-27 17:21 ` Linus Torvalds
2011-05-27 17:46 ` Ingo Molnar
2011-05-27 17:53 ` H. Peter Anvin
2011-05-27 18:05 ` Linus Torvalds
2011-05-27 19:15 ` Vivek Goyal
2011-05-27 21:37 ` H. Peter Anvin
2011-05-27 23:51 ` H. Peter Anvin
2011-05-28 12:18 ` Ingo Molnar
2011-05-29 1:13 ` H. Peter Anvin
2011-05-29 12:47 ` Ingo Molnar
2011-05-29 18:19 ` H. Peter Anvin
2011-05-29 18:44 ` Ingo Molnar
2011-05-29 18:52 ` H. Peter Anvin
2011-05-29 19:56 ` Ingo Molnar
2011-05-27 17:57 ` Linus Torvalds
2011-05-27 18:17 ` Ingo Molnar
2011-05-27 18:43 ` Kees Cook
2011-05-27 18:48 ` david
2011-05-27 21:51 ` Olivier Galibert
2011-05-27 22:11 ` Valdis.Kletnieks
2011-05-28 0:50 ` H. Peter Anvin
2011-05-28 6:32 ` Ingo Molnar
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=1306340141.2211.32.camel@dan \
--to=drosenberg@vsecurity.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=davej@redhat.com \
--cc=davem@davemloft.net \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=kees.cook@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pageexec@freemail.hu \
--cc=penberg@kernel.org \
--cc=tony.luck@gmail.com \
--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.