From: Dave Young <dyoung@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: kaslr should avoid setup_data region
Date: Fri, 9 May 2014 11:21:43 +0800 [thread overview]
Message-ID: <20140509032143.GA3087@darkstar.nay.redhat.com> (raw)
In-Reply-To: <CAGXu5j+VbEYWH80mvY3wQscqqfkDpKkKv81xQa-qmUz-mqHF2Q@mail.gmail.com>
On 05/08/14 at 12:31pm, Kees Cook wrote:
> On Thu, May 8, 2014 at 2:46 AM, Dave Young <dyoung@redhat.com> wrote:
> > On 04/24/14 at 03:50pm, Kees Cook wrote:
> >> On Wed, Apr 23, 2014 at 7:50 PM, Dave Young <dyoung@redhat.com> wrote:
> >> > On 04/23/14 at 07:43pm, Kees Cook wrote:
> >> >> On Wed, Apr 23, 2014 at 7:35 PM, Dave Young <dyoung@redhat.com> wrote:
> >> >> > Hello Kees
> >> >> >
> >> >> > I'm worrying that setup_data regions could be overwitten by randomize
> >> >> > kernel base. Would you like to fix it in kaslr code?
> >> >> >
> >> >> > One problem is there could be a lot of setup_data regions but current
> >> >> > mem_avoid is an fixed array.
> >> >>
> >> >> Sure, can you give me some examples? Seems like it shouldn't be too
> >> >> hard to have the mem_avoid logic walk additional areas.
> >> >
> >> > Great, To walk through the list just like the function parse_setup_data in
> >> > arch/x86/kernel/setup.c
> >
> > One problem for me is that I am not sure how to read the setup_data memory
> > and iterate it, I think early_ioremap is not available that early. BTW the
> > setup_data region could be above 4G.
> >
> > Appreciate for any hints.
>
> Hm, I'm not sure. The kASLR code only deals with memory that has been
> set up during the physical/virtual identity mapping.
>
So will dereference them directly and ignore setup_data which is above 4G.
Thanks
Dave
prev parent reply other threads:[~2014-05-09 3:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-24 2:35 kaslr should avoid setup_data region Dave Young
2014-04-24 2:43 ` Kees Cook
2014-04-24 2:50 ` Dave Young
2014-04-24 22:50 ` Kees Cook
2014-04-24 23:46 ` H. Peter Anvin
2014-04-25 9:44 ` Dave Young
2014-05-05 8:58 ` Dave Young
2014-05-08 9:46 ` Dave Young
2014-05-08 19:31 ` Kees Cook
2014-05-09 3:21 ` Dave Young [this message]
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=20140509032143.GA3087@darkstar.nay.redhat.com \
--to=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.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.