All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <keescook@chromium.org>, Baoquan He <bhe@redhat.com>,
	Yinghai Lu <yinghai@kernel.org>, Ingo Molnar <mingo@redhat.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Andy Lutomirski <luto@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET
Date: Fri, 22 Apr 2016 11:43:46 +0200	[thread overview]
Message-ID: <20160422094346.GA15172@pd.tnic> (raw)
In-Reply-To: <20160422071612.GA6819@gmail.com>

On Fri, Apr 22, 2016 at 09:16:12AM +0200, Ingo Molnar wrote:
> 
> * Kees Cook <keescook@chromium.org> wrote:
> 
> > >> +       Since the kernel is built using 2GB addressing,
> > >
> > > Does that try to refer to the 1G kernel and 1G fixmap pagetable
> > > mappings? I.e., level2_kernel_pgt and level2_fixmap_pgt in
> > > arch/x86/kernel/head_64.S?
> > 
> > The "2GB addressing" part is in reference to:
> > 
> >        -mcmodel=kernel
> >            Generate code for the kernel code model.  The kernel runs in the
> >            negative 2 GB of the address space.  This model has to be used for
> >            Linux kernel code.
> 
> On x86-64 this is a special GCC compiler small memory model, it is called the 
> 'kernel code model', which is rather generic and no 'real name' ever stuck.
> 
> Due to RIP-relative addressing and the sign-extension of 48 bit virtual addresses, 
> this allows nearly as compact kernel code and (static) kernel data definitions as 
> a 32-bit kernel would allow.
> 
> The (positive) 0-4GB virtual memory range has similar advantages, but is of course 
> frequently used by user-space code. Negative addresses are reserved for the kernel 
> only.

So it wouldn't hurt to have a more detailed explanation like this one in
the text. And the 2G thing confused me maybe because it actually means
32-bit: 0x8000_0000 is 2G and is negative since the MSB is 1b. And I was
wondering: "but what about 64-bit...?"

Thanks.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2016-04-22  9:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 20:55 [PATCH 0/5] x86, boot: clean up KASLR code (step 2) Kees Cook
2016-04-20 20:55 ` [PATCH 1/5] x86, KASLR: Update description for decompressor worst case size Kees Cook
2016-04-21 14:47   ` Borislav Petkov
2016-04-21 20:04     ` Kees Cook
2016-04-22  3:13       ` Baoquan He
2016-04-22  7:41   ` Ingo Molnar
2016-04-22  9:45   ` [tip:x86/boot] x86/KASLR: " tip-bot for Baoquan He
2016-04-20 20:55 ` [PATCH 2/5] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Kees Cook
2016-04-21 17:44   ` Borislav Petkov
2016-04-21 18:13     ` Kees Cook
2016-04-22  7:16       ` Ingo Molnar
2016-04-22  9:43         ` Borislav Petkov [this message]
2016-04-22  9:45   ` [tip:x86/boot] x86/KASLR: " tip-bot for Baoquan He
2016-04-20 20:55 ` [PATCH 3/5] x86, boot: Clean up things used by decompressors Kees Cook
2016-04-22  9:46   ` [tip:x86/boot] x86/boot: " tip-bot for Kees Cook
2016-04-20 20:55 ` [PATCH 4/5] x86, boot: Make memcpy handle overlaps Kees Cook
2016-04-22  7:49   ` Ingo Molnar
2016-04-22 22:18     ` Kees Cook
2016-04-22  7:56   ` Ingo Molnar
2016-04-22  9:46   ` [tip:x86/boot] x86/boot: Make memcpy() " tip-bot for Kees Cook
2016-04-22 21:05     ` Lasse Collin
2016-04-22 22:01       ` Kees Cook
2016-04-20 20:55 ` [PATCH 5/5] x86, KASLR: Warn when KASLR is disabled Kees Cook
2016-04-22  9:47   ` [tip:x86/boot] x86/KASLR: " tip-bot for Kees Cook
2016-04-22  7:43 ` [PATCH 0/5] x86, boot: clean up KASLR code (step 2) Ingo Molnar
2016-04-22 15:39   ` 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=20160422094346.GA15172@pd.tnic \
    --to=bp@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=bhe@redhat.com \
    --cc=dvyukov@google.com \
    --cc=hjl.tools@gmail.com \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --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.