lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Oct 2014 08:49:32 -0400
From:	Vivek Goyal <>
To:	"H. Peter Anvin" <>
Cc:	Baoquan He <>, Kees Cook <>,,,,,,,,,,
Subject: Re: [resend Patch v3 1/2] kaslr: check if kernel location is changed

On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
> On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
> > On 10/13/2014 08:19 AM, Vivek Goyal wrote:
> > >>>
> > >>> This really shouldn't have happened this way on x86-64.  It has to happen
> > >>> this way on i386, but I worry that this may be a serious misdesign in kaslr
> > >>> on x86-64.  I'm also wondering if there is any other fallout of this?
> > >>
> > >> I agree. On x86_64, we should stick to previous design and this new
> > >> logic of performing relocations does not sound very clean and makes
> > >> things very confusing.
> > >>
> > >> I am wondering that why couldn't we simply adjust page tables in case of
> > >> kaslr on x86_64, instead of performing relocations.
> > > 
> > > Well, IIUC, if virtual addresses are shifted w.r.t what virtual address
> > > kernel was compiled for, then relocation will have to be done.
> > > 
> > > So question will be if physical address shift is enough for kaslr or
> > > virtual address shift is necessary.
> > > 
> > 
> > I would assume that without a virtual address shift kaslr is pretty darn
> > pointless.  Without the physical address shift the 1:1 map can be used,
> > and again, kaslr becomes pointless.  However, there is absolutely no
> > reason why they should be coupled.  They can, in fact, be independently
> > randomized.
> Agreed. On x86_64, we should be able to randomize virtual address space
> and physical address space independently. And in that case whole of
> the physical memory should be available for a possible location for
> kernel. (As opposed to a small limit (I guess 1GB) now)

Hi Peter,

So what do we do about this issue in short term to make kexec work. Even
if we go for above solution, to make kexec work we will have to pass
"nokaslr" as we don't want kernel to move around in physical address space
as it might stomp over ELF headers we have stored.

If you don't like current patch, should we just disable relocations in
x86_64 if "nokaslr" command line is passed. That way kernel will not
be moved in physical as well as virtual address space.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists