From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Baoquan He <bhe@redhat.com>, Borislav Petkov <bp@suse.de>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "x86@kernel.org" <x86@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v9 3/5] x86/KASLR: Randomize virtual address separately
Date: Fri, 17 Jun 2016 10:35:35 +0200 [thread overview]
Message-ID: <20160617083535.GA6996@gmail.com> (raw)
In-Reply-To: <20160617082026.GA4791@gmail.com>
* Ingo Molnar <mingo@kernel.org> wrote:
>
> * Kees Cook <keescook@chromium.org> wrote:
>
> > -unsigned char *choose_random_location(unsigned long input,
> > - unsigned long input_size,
> > - unsigned long output,
> > - unsigned long output_size)
> > +void choose_random_location(unsigned long input,
> > + unsigned long input_size,
> > + unsigned long *output,
> > + unsigned long output_size,
> > + unsigned long *virt_addr)
> > {
> > - unsigned long choice = output;
> > unsigned long random_addr;
> >
> > + /* By default, keep output position unchanged. */
> > + *virt_addr = *output;
>
> So I applied this, after fixing a conflict with a recent hibernation related
> change, but it would be nice to further clean up the types in this file, in
> particular could we please propagate 'const' for all input-only pointers?
>
> For example in the above function it would be obvious at a glance if it said
> something like:
>
> void choose_random_location(unsigned long input,
> unsigned long input_size,
> const unsigned long *output,
> unsigned long output_size,
> unsigned long *virt_addr)
>
> when reading such a function prototype I can immediately tell: 'yeah, while it's
> named "output", it's in fact a read-only input parameter - the _real_ output of
> the function is 'virt_addr'.)
Doh, so I managed to confuse myself by looking at the unpatched function only.
This patch in fact starts writing to 'output':
+ /* Update the new physical address location. */
+ if (*output != random_addr) {
+ add_identity_map(random_addr, output_size);
+ *output = random_addr;
+ }
At which point 'output' cannot be const, and in fact it might be beneficial that
'virt_addr' is passed in by a pointer as well.
The comment of the function definitely needs to be updated:
* it takes the input and output pointers as 'unsigned long'.
... which is not true anymore.
I also find the type flow and naming for the 'output' pointer very confusing. We
have:
asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
unsigned char *input_data,
unsigned long input_len,
unsigned char *output,
unsigned long output_len)
...
choose_random_location((unsigned long)input_data, input_len,
(unsigned long *)&output,
max(output_len, kernel_total_size),
&virt_addr);
void choose_random_location(unsigned long input,
unsigned long input_size,
unsigned long *output,
unsigned long output_size,
unsigned long *virt_addr)
...
*output = random_addr;
it is very easy to confuse 'unsigned long *output' with the 'char *output' pointer
to the output stream! But in reality this is a double pointer and we want to use
it to change the pointer.
So at minimum we should rename 'output' in choose_random_location() to something
like 'output_ptr' - but even better would be to just preserve its natural type and
use 'char * const *' and do a single type cast when setting it.
Same goes for 'virt_addr'.
Agreed?
Thanks,
Ingo
next prev parent reply other threads:[~2016-06-17 8:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-25 22:45 [PATCH v9 0/5] x86/KASLR: Randomize virtual address separately Kees Cook
2016-05-25 22:45 ` [PATCH v9 1/5] x86/boot: Refuse to build with data relocations Kees Cook
2016-06-17 12:22 ` [tip:x86/boot] " tip-bot for Kees Cook
2016-06-26 11:01 ` tip-bot for Kees Cook
2016-05-25 22:45 ` [PATCH v9 2/5] x86/KASLR: Clarify identity map interface Kees Cook
2016-06-17 12:22 ` [tip:x86/boot] " tip-bot for Kees Cook
2016-06-26 11:02 ` tip-bot for Kees Cook
2016-05-25 22:45 ` [PATCH v9 3/5] x86/KASLR: Randomize virtual address separately Kees Cook
2016-06-17 8:20 ` Ingo Molnar
2016-06-17 8:35 ` Ingo Molnar [this message]
2016-06-17 12:22 ` [tip:x86/boot] " tip-bot for Baoquan He
2016-06-26 11:02 ` tip-bot for Baoquan He
2016-05-25 22:45 ` [PATCH v9 4/5] x86/KASLR: Add physical address randomization >4G Kees Cook
2016-06-17 12:23 ` [tip:x86/boot] x86/KASLR: Extend kernel image physical address randomization to addresses larger than 4G tip-bot for Kees Cook
2016-06-26 11:02 ` tip-bot for Kees Cook
2016-05-25 22:45 ` [PATCH v9 5/5] x86/KASLR: Allow randomization below load address Kees Cook
2016-06-17 8:47 ` Ingo Molnar
2016-06-17 15:44 ` Kees Cook
2016-06-17 18:44 ` Yinghai Lu
2016-06-17 12:23 ` [tip:x86/boot] x86/KASLR: Allow randomization below the " tip-bot for Yinghai Lu
2016-06-26 11:03 ` tip-bot for Yinghai Lu
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=20160617083535.GA6996@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=bhe@redhat.com \
--cc=bp@suse.de \
--cc=dvyukov@google.com \
--cc=hjl.tools@gmail.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--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 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.