[kexec-tools PATCH] x86: extend kernel text size up to 1GB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/14/14 at 02:47pm, Dave Young wrote:
> On 03/14/14 at 02:12pm, Dave Young wrote:
> > On 03/12/14 at 11:13am, WANG Chao wrote:
> > > Currently kexec hard code X86_64_KERNEL_TEXT_SIZE to 512M. With kASLR
> > > enabled (CONFIG_RANDOMIZED_BASE=y), kernel image base offset could be
> > > randomized from 0 to 1GB and kexec-tools fails to get kernel virtual
> > > address from /proc/kcore when the offset is >512M.
> > > 
> > > Now extend X86_64_KERNEL_TEXT_SIZE to 1GB to adapt kASLR.
> > > 
> > > Signed-off-by: WANG Chao <chaowang at redhat.com>
> > > ---
> > >  kexec/arch/i386/crashdump-x86.h | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch/i386/crashdump-x86.h
> > > index e68b626..a5b2dfd 100644
> > > --- a/kexec/arch/i386/crashdump-x86.h
> > > +++ b/kexec/arch/i386/crashdump-x86.h
> > > @@ -18,7 +18,7 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
> > >  #define X86_64_MAXMEM        		0x3fffffffffffUL
> > >  
> > >  /* Kernel text size */
> > > -#define X86_64_KERNEL_TEXT_SIZE  (512UL*1024*1024)
> > > +#define X86_64_KERNEL_TEXT_SIZE  (1UL*1024*1024*1024)
> > 
> > Should define a new macro such as: X86_KERNEL_TEXT_START_LIMIT (1UL*1024*1024*1024)
> > and then check end addr with X86_64_KERNEL_TEXT_SIZE + X86_64_KERNEL_TEXT_SIZE
> 
> I means check ktext with range <1G - 1.5G>

You're right.

I think it's fine adding new macro X86_64_RANDOMIZE_BASE_MAX_OFFSET
as 0x40000000 (1G) and doing the following check:

(start >= X86_64__START_KERNEL_map) &&
 (start <= X86_64__START_KERNEL_map + X86_64_RANDOMIZE_MAX_BASE_OFFSET) &&
 (end - start <= X86_64_KERNEL_TEXT_SIZE)

What do you think?

> 
> > 
> > Previously I did not find this problem probably because kernel text happen to randomized
> > to a address < 512M..
> > 
> > BTW since we can get physical start and size from /proc/iomem, why not just get
> > vaddr by phys_start + PAGE_OFFSET.
> 
> Ignore above question, /proc/iomem can not get right end addr which includes not only code
> and data.
> 
> Current kaslr has a limit up value 0x40000000 in Kconfig so the biggest value is 1G, but
> it could be change to other value in the future. It will be ideal that we can export the
> end addr somewhere for example /proc/iomem. 

We have to use kcore to determine start/end until something happens in
/proc/iomem or elsewhere.

Thanks
WANG Chao

> 
> > 
> > >  
> > >  #define CRASH_MAX_MEMMAP_NR	CRASH_MAX_MEMORY_RANGES
> > >  #define CRASH_MAX_MEMORY_RANGES	(MAX_MEMORY_RANGES + 2)
> > > -- 
> > > 1.8.5.3
> > > 
> > > 
> > > _______________________________________________
> > > kexec mailing list
> > > kexec at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/kexec



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux