From: Vivek Goyal <vgoyal@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Baoquan He <bhe@redhat.com>,
linux-kernel@vger.kernel.org, ak@linux.intel.com,
mingo@redhat.com, whissi@whissi.de, dyoung@redhat.com,
tglx@linutronix.de, chaowang@redhat.com,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 3/4] kaslr setup_data handling
Date: Tue, 9 Sep 2014 15:45:00 -0400 [thread overview]
Message-ID: <20140909194500.GB20681@redhat.com> (raw)
In-Reply-To: <20140905173256.GV5598@outflux.net>
On Fri, Sep 05, 2014 at 10:32:56AM -0700, Kees Cook wrote:
> On Fri, Sep 05, 2014 at 10:08:16PM +0800, Baoquan He wrote:
> > From: Dave Young <dyoung@redhat.com>
> >
> > X86 will pass setup_data region while necessary, these regions could be
> > overwitten by kernel due to kaslr.
> >
> > Thus iterate and add setup regions to mem_avoid[] in this patch.
> > Up to now there isn't a official data to state the maximal entries
> > setup data could use. So just set max mem avoid entries 32, hopefully
> > it will be enough. This can be increased later when people report
> > they are using more setup data entries.
>
> Ew, yes, this is bad. I hadn't seen setup_data while designing the
> mem_avoid stuff. I don't like the fixed 32 entry size here, so let me
> consider some options. I think the mem_avoid logic can just walk the
> setup_data list itself, since that's what it's for. :)
>
> Does only kexec use this? I assume other boot loaders must be using this
> too. Is there an easy test case for validating this is fixed?
[CC hpa]
I think this is generic mechanism and any bootloader can make use of it.
May be testing it using kexec on an EFI machine might work as kexec
prepares setup_data entry to pass some information to second kernel.
Thanks
Vivek
>
> >
> > Signed-off-by: Dave Young <dyoung@redhat.com>
> > Signed-off-by: Baoquan He <bhe@redhat.com>
> > ---
> > arch/x86/boot/compressed/aslr.c | 29 +++++++++++++++++++++++++++--
> > 1 file changed, 27 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
> > index 975b07b..7e92fc8 100644
> > --- a/arch/x86/boot/compressed/aslr.c
> > +++ b/arch/x86/boot/compressed/aslr.c
> > @@ -110,8 +110,9 @@ struct mem_vector {
> > unsigned long size;
> > };
> >
> > -#define MEM_AVOID_MAX 5
> > +#define MEM_AVOID_MAX 32
> > static struct mem_vector mem_avoid[MEM_AVOID_MAX];
> > +static int mem_avoid_nr;
> >
> > static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
> > {
> > @@ -135,6 +136,27 @@ static bool mem_overlaps(struct mem_vector *one, struct mem_vector *two)
> > return true;
> > }
> >
> > +static void mem_avoid_setup_data(void)
> > +{
> > + struct setup_data *data;
> > + u64 pa_data;
> > +
> > + pa_data = real_mode->hdr.setup_data;
> > + while (pa_data) {
> > + if (mem_avoid_nr >= MEM_AVOID_MAX) {
> > + debug_putstr("KASLR: too many setup_data ranges.\n");
> > + return;
> > + }
> > + data = (struct setup_data *)pa_data;
> > + if (pa_data < CONFIG_RANDOMIZE_BASE_MAX_OFFSET) {
> > + mem_avoid[mem_avoid_nr].start = pa_data;
> > + mem_avoid[mem_avoid_nr].size = sizeof(*data) + data->len;
> > + mem_avoid_nr++;
> > + }
> > + pa_data = data->next;
> > + }
> > +}
> > +
> > static void mem_avoid_init(unsigned long input, unsigned long input_size,
> > unsigned long output, unsigned long output_size)
> > {
> > @@ -177,6 +199,9 @@ static void mem_avoid_init(unsigned long input, unsigned long input_size,
> > /* Avoid stack memory. */
> > mem_avoid[4].start = (unsigned long)free_mem_end_ptr;
> > mem_avoid[4].size = BOOT_STACK_SIZE;
> > + mem_avoid_nr = 5;
> > +
> > + mem_avoid_setup_data();
> > }
> >
> > /* Does this memory vector overlap a known avoided area? */
> > @@ -184,7 +209,7 @@ static bool mem_avoid_overlap(struct mem_vector *img)
> > {
> > int i;
> >
> > - for (i = 0; i < MEM_AVOID_MAX; i++) {
> > + for (i = 0; i < mem_avoid_nr; i++) {
> > if (mem_overlaps(img, &mem_avoid[i]))
> > return true;
> > }
> > --
> > 1.8.5.3
>
> Here's an alternative... can you test it?
>
> ---
> Subject: x86, kaslr: avoid setup_data when choosing kernel location
>
> The KASLR location-choosing logic needs to avoid the setup_data list
> areas as well.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Cc: stable@vger.kernel.org
>
> diff --git a/arch/x86/boot/compressed/aslr.c b/arch/x86/boot/compressed/aslr.c
> index fc6091abedb7..7c75c22d9bc3 100644
> --- a/arch/x86/boot/compressed/aslr.c
> +++ b/arch/x86/boot/compressed/aslr.c
> @@ -112,6 +112,7 @@ struct mem_vector {
>
> #define MEM_AVOID_MAX 5
> static struct mem_vector mem_avoid[MEM_AVOID_MAX];
> +static struct setup_data *setup_data_avoid;
>
> static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
> {
> @@ -177,17 +178,30 @@ static void mem_avoid_init(unsigned long input, unsigned long input_size,
> /* Avoid stack memory. */
> mem_avoid[4].start = (unsigned long)free_mem_end_ptr;
> mem_avoid[4].size = BOOT_STACK_SIZE;
> +
> + /* Locate the setup_data list, if it exists. */
> + setup_data_avoid = (struct setup_data *)real_mode->hdr.setup_data;
> }
>
> /* Does this memory vector overlap a known avoided area? */
> static bool mem_avoid_overlap(struct mem_vector *img)
> {
> int i;
> + struct setup_data *ptr;
>
> for (i = 0; i < MEM_AVOID_MAX; i++) {
> if (mem_overlaps(img, &mem_avoid[i]))
> return true;
> }
> + for (ptr = setup_data_avoid; ptr; ptr = ptr->next) {
> + struct mem_vector avoid;
> +
> + avoid.start = (u64)ptr;
> + avoid.size = sizeof(*ptr) + ptr->len;
> +
> + if (mem_overlaps(img, &avoid))
> + return true;
> + }
>
> return false;
> }
>
> --
> Kees Cook
> Chrome OS Security
next prev parent reply other threads:[~2014-09-09 19:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-05 14:08 [PATCH 0/4] fix the compatibility between kaslr and kexe Baoquan He
2014-09-05 14:08 ` [PATCH 1/4] kaslr: check user's config too when handle relocations Baoquan He
2014-09-05 17:11 ` Kees Cook
2014-09-05 22:37 ` Baoquan He
2014-09-09 6:24 ` Baoquan He
2014-09-09 15:53 ` Kees Cook
2014-09-09 19:28 ` Vivek Goyal
2014-09-09 21:13 ` Kees Cook
2014-09-10 7:21 ` Baoquan He
2014-09-10 14:30 ` Vivek Goyal
2014-09-10 14:41 ` Kees Cook
2014-09-10 15:05 ` Vivek Goyal
2014-09-10 15:27 ` Baoquan He
2014-09-10 15:38 ` Vivek Goyal
2014-09-11 9:31 ` Baoquan He
2014-09-11 16:18 ` Kees Cook
2014-09-10 14:53 ` Baoquan He
2014-09-10 15:04 ` Vivek Goyal
2014-09-10 15:13 ` Baoquan He
2014-09-10 6:10 ` Baoquan He
2014-09-10 13:20 ` Vivek Goyal
2014-09-05 14:08 ` [PATCH 2/4] kaslr: check if the random addr is available Baoquan He
2014-09-05 17:16 ` Kees Cook
2014-09-05 22:16 ` Baoquan He
2014-09-09 19:41 ` Vivek Goyal
2014-09-10 13:55 ` Baoquan He
2014-09-05 14:08 ` [PATCH 3/4] kaslr setup_data handling Baoquan He
2014-09-05 17:32 ` Kees Cook
2014-09-05 22:27 ` Baoquan He
2014-09-09 19:45 ` Vivek Goyal [this message]
2014-09-09 19:49 ` H. Peter Anvin
2014-09-09 21:10 ` Kees Cook
2014-09-05 14:08 ` [PATCH 4/4] export the kernel image size KERNEL_IMAGE_SIZE Baoquan He
2014-09-05 17:00 ` Kees Cook
2014-09-09 19:47 ` Vivek Goyal
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=20140909194500.GB20681@redhat.com \
--to=vgoyal@redhat.com \
--cc=ak@linux.intel.com \
--cc=bhe@redhat.com \
--cc=chaowang@redhat.com \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=whissi@whissi.de \
/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.