From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Borislav Petkov <bp@suse.de>, Yinghai Lu <yinghai@kernel.org>,
Baoquan He <bhe@redhat.com>, Ingo Molnar <mingo@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
Vivek Goyal <vgoyal@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Lasse Collin <lasse.collin@tukaani.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Young <dyoung@redhat.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 1/4] x86/KASLR: Clarify identity map interface
Date: Thu, 12 May 2016 10:30:40 +0200 [thread overview]
Message-ID: <20160512083040.GA26457@gmail.com> (raw)
In-Reply-To: <CAGXu5j+4N0YSkEb54k6Wj6oZW8OKTwS12LtajTnerw03knRimw@mail.gmail.com>
* Kees Cook <keescook@chromium.org> wrote:
> On Tue, May 10, 2016 at 11:24 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Kees Cook <keescook@chromium.org> wrote:
> >
> >> +/*
> >> + * Mapping information structure passed to kernel_ident_mapping_init().
> >> + * Due to relocation, pointers must be assigned at run time not build time.
> >> + */
> >> +static struct x86_mapping_info mapping_info = {
> >> + .pmd_flag = __PAGE_KERNEL_LARGE_EXEC,
> >> +};
> >
> >> +void initialize_identity_maps(void)
> >> {
> >> + /* Init mapping_info with run-time function/buffer pointers. */
> >> + mapping_info.alloc_pgt_page = alloc_pgt_page;
> >> + mapping_info.context = &pgt_data;
> >
> > Could you please outline the precise failure mode? What gets executed when, which
> > pointer gets relocated and which not, and exactly when does it pose a problem,
> > etc.
>
> It's the issue described at the top of misc.c:
>
> /*
> * WARNING!!
> * This code is compiled with -fPIC and it is relocated dynamically at
> * run time, but no relocation processing is performed. This means that
> * it is not safe to place pointers in static structures.
So I think this is still a bit confusing: what's the difference between 'relocated
dynamically at run time' and 'relocation processing'?
So 'to relocate code' usually means the whole deal: 'copy code and fix up'.
The problem here is that we copy the code to an address not known at build time,
but don't fix it up (because this is the fixup code), right?
Thanks,
Ingo
next prev parent reply other threads:[~2016-05-12 8:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 17:19 [PATCH v8 0/4] x86/KASLR: Randomize virtual address separately Kees Cook
2016-05-10 17:19 ` [PATCH v8 1/4] x86/KASLR: Clarify identity map interface Kees Cook
2016-05-10 17:44 ` Borislav Petkov
2016-05-11 6:24 ` Ingo Molnar
2016-05-11 15:23 ` Kees Cook
2016-05-12 8:30 ` Ingo Molnar [this message]
2016-05-12 8:31 ` Ingo Molnar
2016-05-10 17:19 ` [PATCH v8 2/4] x86/KASLR: Randomize virtual address separately Kees Cook
2016-05-10 17:19 ` [PATCH v8 3/4] x86/KASLR: Add physical address randomization >4G Kees Cook
2016-05-10 17:19 ` [PATCH v8 4/4] x86/KASLR: Allow randomization below load address Kees Cook
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=20160512083040.GA26457@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=lasse.collin@tukaani.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=vgoyal@redhat.com \
--cc=yinghai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).