* [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
@ 2014-03-14 8:20 WANG Chao
2014-03-17 3:27 ` Dave Young
2014-03-17 12:56 ` Vivek Goyal
0 siblings, 2 replies; 7+ messages in thread
From: WANG Chao @ 2014-03-14 8:20 UTC (permalink / raw)
To: kexec; +Cc: dyoung, ebiederm, vgoyal
With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
assumes kernel vaddr start/end is within the range [0,512M). If kaslr
enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
To adapt kaslr, introduce a new macro X86_64_RANDOMIZED_BASE_MAX_OFFSET
to address the max offset and use this macro to filter out the kernel
text PT_LOAD from /proc/kcore.
Signed-off-by: WANG Chao <chaowang@redhat.com>
---
kexec/arch/i386/crashdump-x86.c | 3 ++-
kexec/arch/i386/crashdump-x86.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index cb19e7d..1e6d3a3 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -156,7 +156,8 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
/* Look for kernel text mapping header. */
if ((saddr >= X86_64__START_KERNEL_map) &&
- (eaddr <= X86_64__START_KERNEL_map + X86_64_KERNEL_TEXT_SIZE)) {
+ (saddr <= X86_64__START_KERNEL_map + X86_64_RANDOMIZE_BASE_MAX_OFFSET) &&
+ (eaddr - saddr < X86_64_KERNEL_TEXT_SIZE)) {
saddr = _ALIGN_DOWN(saddr, X86_64_KERN_VADDR_ALIGN);
elf_info->kern_vaddr_start = saddr;
size = eaddr - saddr;
diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch/i386/crashdump-x86.h
index e68b626..71a09f8 100644
--- a/kexec/arch/i386/crashdump-x86.h
+++ b/kexec/arch/i386/crashdump-x86.h
@@ -15,6 +15,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
#define X86_64_PAGE_OFFSET_PRE_2_6_27 0xffff810000000000ULL
#define X86_64_PAGE_OFFSET 0xffff880000000000ULL
+/* kASLR - Kernel base offset could be randomized up to 1G */
+#define X86_64_RANDOMIZE_BASE_MAX_OFFSET 0x40000000
+
#define X86_64_MAXMEM 0x3fffffffffffUL
/* Kernel text size */
--
1.8.5.3
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
2014-03-14 8:20 [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset WANG Chao
@ 2014-03-17 3:27 ` Dave Young
2014-03-17 12:56 ` Vivek Goyal
1 sibling, 0 replies; 7+ messages in thread
From: Dave Young @ 2014-03-17 3:27 UTC (permalink / raw)
To: WANG Chao; +Cc: kexec, ebiederm, vgoyal
On 03/14/14 at 04:20pm, WANG Chao wrote:
> With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
> base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
>
> Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
> assumes kernel vaddr start/end is within the range [0,512M). If kaslr
> enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
>
> To adapt kaslr, introduce a new macro X86_64_RANDOMIZED_BASE_MAX_OFFSET
> to address the max offset and use this macro to filter out the kernel
> text PT_LOAD from /proc/kcore.
>
> Signed-off-by: WANG Chao <chaowang@redhat.com>
> ---
> kexec/arch/i386/crashdump-x86.c | 3 ++-
> kexec/arch/i386/crashdump-x86.h | 3 +++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> index cb19e7d..1e6d3a3 100644
> --- a/kexec/arch/i386/crashdump-x86.c
> +++ b/kexec/arch/i386/crashdump-x86.c
> @@ -156,7 +156,8 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
>
> /* Look for kernel text mapping header. */
> if ((saddr >= X86_64__START_KERNEL_map) &&
> - (eaddr <= X86_64__START_KERNEL_map + X86_64_KERNEL_TEXT_SIZE)) {
> + (saddr <= X86_64__START_KERNEL_map + X86_64_RANDOMIZE_BASE_MAX_OFFSET) &&
> + (eaddr - saddr < X86_64_KERNEL_TEXT_SIZE)) {
> saddr = _ALIGN_DOWN(saddr, X86_64_KERN_VADDR_ALIGN);
> elf_info->kern_vaddr_start = saddr;
> size = eaddr - saddr;
> diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch/i386/crashdump-x86.h
> index e68b626..71a09f8 100644
> --- a/kexec/arch/i386/crashdump-x86.h
> +++ b/kexec/arch/i386/crashdump-x86.h
> @@ -15,6 +15,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
> #define X86_64_PAGE_OFFSET_PRE_2_6_27 0xffff810000000000ULL
> #define X86_64_PAGE_OFFSET 0xffff880000000000ULL
>
> +/* kASLR - Kernel base offset could be randomized up to 1G */
> +#define X86_64_RANDOMIZE_BASE_MAX_OFFSET 0x40000000
> +
> #define X86_64_MAXMEM 0x3fffffffffffUL
>
> /* Kernel text size */
Acked-by: Dave Young <dyoung@redhat.com>
Thanks
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
2014-03-14 8:20 [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset WANG Chao
2014-03-17 3:27 ` Dave Young
@ 2014-03-17 12:56 ` Vivek Goyal
2014-03-19 7:05 ` WANG Chao
1 sibling, 1 reply; 7+ messages in thread
From: Vivek Goyal @ 2014-03-17 12:56 UTC (permalink / raw)
To: WANG Chao; +Cc: dyoung, kexec, ebiederm
On Fri, Mar 14, 2014 at 04:20:18PM +0800, WANG Chao wrote:
> With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
> base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
>
> Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
> assumes kernel vaddr start/end is within the range [0,512M). If kaslr
> enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
Hi Chao,
Documentation/x86/x86_64/mm.txt still says that kernel text mapping area
is 512MB.
ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from
phys 0
So has that changed now due to kASLR.
Thanks
Vivek
>
> To adapt kaslr, introduce a new macro X86_64_RANDOMIZED_BASE_MAX_OFFSET
> to address the max offset and use this macro to filter out the kernel
> text PT_LOAD from /proc/kcore.
>
> Signed-off-by: WANG Chao <chaowang@redhat.com>
> ---
> kexec/arch/i386/crashdump-x86.c | 3 ++-
> kexec/arch/i386/crashdump-x86.h | 3 +++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> index cb19e7d..1e6d3a3 100644
> --- a/kexec/arch/i386/crashdump-x86.c
> +++ b/kexec/arch/i386/crashdump-x86.c
> @@ -156,7 +156,8 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
>
> /* Look for kernel text mapping header. */
> if ((saddr >= X86_64__START_KERNEL_map) &&
> - (eaddr <= X86_64__START_KERNEL_map + X86_64_KERNEL_TEXT_SIZE)) {
> + (saddr <= X86_64__START_KERNEL_map + X86_64_RANDOMIZE_BASE_MAX_OFFSET) &&
> + (eaddr - saddr < X86_64_KERNEL_TEXT_SIZE)) {
> saddr = _ALIGN_DOWN(saddr, X86_64_KERN_VADDR_ALIGN);
> elf_info->kern_vaddr_start = saddr;
> size = eaddr - saddr;
> diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch/i386/crashdump-x86.h
> index e68b626..71a09f8 100644
> --- a/kexec/arch/i386/crashdump-x86.h
> +++ b/kexec/arch/i386/crashdump-x86.h
> @@ -15,6 +15,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
> #define X86_64_PAGE_OFFSET_PRE_2_6_27 0xffff810000000000ULL
> #define X86_64_PAGE_OFFSET 0xffff880000000000ULL
>
> +/* kASLR - Kernel base offset could be randomized up to 1G */
> +#define X86_64_RANDOMIZE_BASE_MAX_OFFSET 0x40000000
> +
> #define X86_64_MAXMEM 0x3fffffffffffUL
>
> /* Kernel text size */
> --
> 1.8.5.3
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
2014-03-17 12:56 ` Vivek Goyal
@ 2014-03-19 7:05 ` WANG Chao
2014-03-19 13:33 ` Vivek Goyal
0 siblings, 1 reply; 7+ messages in thread
From: WANG Chao @ 2014-03-19 7:05 UTC (permalink / raw)
To: Vivek Goyal; +Cc: dyoung, kexec, ebiederm
On 03/17/14 at 08:56am, Vivek Goyal wrote:
> On Fri, Mar 14, 2014 at 04:20:18PM +0800, WANG Chao wrote:
> > With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
> > base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
> >
> > Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
> > assumes kernel vaddr start/end is within the range [0,512M). If kaslr
> > enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
NACK this patch myself.
There are several mistakes I made. I misunderstood some concepts. Then I
realize this kASLR issue is not trivial to fix.
I think if kexec-tools needs to get kernel text mapping from kcore in
kALSR case, the max base offset (CONFIG_RANDOMIZE_MAX_BASE_OFFSET) of
the kernel text area must be exposed to userspace some where. We can use
that value to determine which area is for kernel text mapping and which
is for modules text mapping.
>
> Hi Chao,
>
> Documentation/x86/x86_64/mm.txt still says that kernel text mapping area
> is 512MB.
>
> ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from
> phys 0
>
> So has that changed now due to kASLR.
Yes, with kASLR enabled, kernel text mapping is as following
ffffffff80000000 - (ffffffff80000000+CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
That said, if using CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x40000000 by
default, the kernel text mapping is as following:
ffffffff80000000 - ffffffffc0000000
Thanks
WANG Chao
>
> Thanks
> Vivek
>
> >
> > To adapt kaslr, introduce a new macro X86_64_RANDOMIZED_BASE_MAX_OFFSET
> > to address the max offset and use this macro to filter out the kernel
> > text PT_LOAD from /proc/kcore.
> >
> > Signed-off-by: WANG Chao <chaowang@redhat.com>
> > ---
> > kexec/arch/i386/crashdump-x86.c | 3 ++-
> > kexec/arch/i386/crashdump-x86.h | 3 +++
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> > index cb19e7d..1e6d3a3 100644
> > --- a/kexec/arch/i386/crashdump-x86.c
> > +++ b/kexec/arch/i386/crashdump-x86.c
> > @@ -156,7 +156,8 @@ static int get_kernel_vaddr_and_size(struct kexec_info *UNUSED(info),
> >
> > /* Look for kernel text mapping header. */
> > if ((saddr >= X86_64__START_KERNEL_map) &&
> > - (eaddr <= X86_64__START_KERNEL_map + X86_64_KERNEL_TEXT_SIZE)) {
> > + (saddr <= X86_64__START_KERNEL_map + X86_64_RANDOMIZE_BASE_MAX_OFFSET) &&
> > + (eaddr - saddr < X86_64_KERNEL_TEXT_SIZE)) {
> > saddr = _ALIGN_DOWN(saddr, X86_64_KERN_VADDR_ALIGN);
> > elf_info->kern_vaddr_start = saddr;
> > size = eaddr - saddr;
> > diff --git a/kexec/arch/i386/crashdump-x86.h b/kexec/arch/i386/crashdump-x86.h
> > index e68b626..71a09f8 100644
> > --- a/kexec/arch/i386/crashdump-x86.h
> > +++ b/kexec/arch/i386/crashdump-x86.h
> > @@ -15,6 +15,9 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
> > #define X86_64_PAGE_OFFSET_PRE_2_6_27 0xffff810000000000ULL
> > #define X86_64_PAGE_OFFSET 0xffff880000000000ULL
> >
> > +/* kASLR - Kernel base offset could be randomized up to 1G */
> > +#define X86_64_RANDOMIZE_BASE_MAX_OFFSET 0x40000000
> > +
> > #define X86_64_MAXMEM 0x3fffffffffffUL
> >
> > /* Kernel text size */
> > --
> > 1.8.5.3
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
2014-03-19 7:05 ` WANG Chao
@ 2014-03-19 13:33 ` Vivek Goyal
2014-03-20 5:46 ` WANG Chao
0 siblings, 1 reply; 7+ messages in thread
From: Vivek Goyal @ 2014-03-19 13:33 UTC (permalink / raw)
To: WANG Chao; +Cc: dyoung, kexec, ebiederm
On Wed, Mar 19, 2014 at 03:05:51PM +0800, WANG Chao wrote:
> On 03/17/14 at 08:56am, Vivek Goyal wrote:
> > On Fri, Mar 14, 2014 at 04:20:18PM +0800, WANG Chao wrote:
> > > With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
> > > base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
> > >
> > > Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
> > > assumes kernel vaddr start/end is within the range [0,512M). If kaslr
> > > enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
>
> NACK this patch myself.
>
> There are several mistakes I made. I misunderstood some concepts. Then I
> realize this kASLR issue is not trivial to fix.
>
> I think if kexec-tools needs to get kernel text mapping from kcore in
> kALSR case, the max base offset (CONFIG_RANDOMIZE_MAX_BASE_OFFSET) of
> the kernel text area must be exposed to userspace some where. We can use
> that value to determine which area is for kernel text mapping and which
> is for modules text mapping.
How about looking at /proc/kallsyms and look at address of one of the
symbols say _text. And search for the ELF header in kcore which contains
_text address and that's ELF header representing kernel text mapping.
That way you don't have to worry about the value of
CONFIG_RANDOMIZE_MAX_BASE_OFFSET.
>
> >
> > Hi Chao,
> >
> > Documentation/x86/x86_64/mm.txt still says that kernel text mapping area
> > is 512MB.
> >
> > ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from
> > phys 0
> >
> > So has that changed now due to kASLR.
>
> Yes, with kASLR enabled, kernel text mapping is as following
>
> ffffffff80000000 - (ffffffff80000000+CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
>
> That said, if using CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x40000000 by
> default, the kernel text mapping is as following:
>
> ffffffff80000000 - ffffffffc0000000
>
Agreed. help text for CONFIG_RANDOMIZE_BASE_MAX_OFFSET says following.
On 64-bit this is limited by how the kernel fixmap page table is
positioned, so this cannot be larger than 1GiB currently. Without
RANDOMIZE_BASE, there is a 512MiB to 1.5GiB split between kernel
and modules. When RANDOMIZE_BASE_MAX_OFFSET is above 512MiB, the
modules area will shrink to compensate, up to the current maximum
1GiB to 1GiB split. The default is 1GiB.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
2014-03-19 13:33 ` Vivek Goyal
@ 2014-03-20 5:46 ` WANG Chao
2014-03-20 15:18 ` Vivek Goyal
0 siblings, 1 reply; 7+ messages in thread
From: WANG Chao @ 2014-03-20 5:46 UTC (permalink / raw)
To: Vivek Goyal; +Cc: dyoung, Simon Horman, kexec, ebiederm
[CC Simon]
On 03/19/14 at 09:33am, Vivek Goyal wrote:
> On Wed, Mar 19, 2014 at 03:05:51PM +0800, WANG Chao wrote:
> > On 03/17/14 at 08:56am, Vivek Goyal wrote:
> > > On Fri, Mar 14, 2014 at 04:20:18PM +0800, WANG Chao wrote:
> > > > With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
> > > > base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
> > > >
> > > > Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
> > > > assumes kernel vaddr start/end is within the range [0,512M). If kaslr
> > > > enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
> >
> > NACK this patch myself.
> >
> > There are several mistakes I made. I misunderstood some concepts. Then I
> > realize this kASLR issue is not trivial to fix.
> >
> > I think if kexec-tools needs to get kernel text mapping from kcore in
> > kALSR case, the max base offset (CONFIG_RANDOMIZE_MAX_BASE_OFFSET) of
> > the kernel text area must be exposed to userspace some where. We can use
> > that value to determine which area is for kernel text mapping and which
> > is for modules text mapping.
>
> How about looking at /proc/kallsyms and look at address of one of the
> symbols say _text. And search for the ELF header in kcore which contains
> _text address and that's ELF header representing kernel text mapping.
Cool. I'd like to go with _stext. _text presents in /proc/kallsyms only
when CONFIG_KALLSYMS_ALL=y. What do you think?
>
> That way you don't have to worry about the value of
> CONFIG_RANDOMIZE_MAX_BASE_OFFSET.
>
> >
> > >
> > > Hi Chao,
> > >
> > > Documentation/x86/x86_64/mm.txt still says that kernel text mapping area
> > > is 512MB.
> > >
> > > ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from
> > > phys 0
> > >
> > > So has that changed now due to kASLR.
> >
> > Yes, with kASLR enabled, kernel text mapping is as following
> >
> > ffffffff80000000 - (ffffffff80000000+CONFIG_RANDOMIZE_BASE_MAX_OFFSET)
> >
> > That said, if using CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x40000000 by
> > default, the kernel text mapping is as following:
> >
> > ffffffff80000000 - ffffffffc0000000
> >
>
> Agreed. help text for CONFIG_RANDOMIZE_BASE_MAX_OFFSET says following.
>
> On 64-bit this is limited by how the kernel fixmap page table is
> positioned, so this cannot be larger than 1GiB currently. Without
> RANDOMIZE_BASE, there is a 512MiB to 1.5GiB split between kernel
> and modules. When RANDOMIZE_BASE_MAX_OFFSET is above 512MiB, the
> modules area will shrink to compensate, up to the current maximum
> 1GiB to 1GiB split. The default is 1GiB.
>
> Thanks
> Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset.
2014-03-20 5:46 ` WANG Chao
@ 2014-03-20 15:18 ` Vivek Goyal
0 siblings, 0 replies; 7+ messages in thread
From: Vivek Goyal @ 2014-03-20 15:18 UTC (permalink / raw)
To: WANG Chao; +Cc: dyoung, Simon Horman, kexec, ebiederm
On Thu, Mar 20, 2014 at 01:46:08PM +0800, WANG Chao wrote:
> [CC Simon]
>
> On 03/19/14 at 09:33am, Vivek Goyal wrote:
> > On Wed, Mar 19, 2014 at 03:05:51PM +0800, WANG Chao wrote:
> > > On 03/17/14 at 08:56am, Vivek Goyal wrote:
> > > > On Fri, Mar 14, 2014 at 04:20:18PM +0800, WANG Chao wrote:
> > > > > With kASLR enabled (CONFIG_RANDOMIZED_BASE=y), kernel virtual address
> > > > > base is PAGE_OFFSET plus a randomized offset from 0 to 1G.
> > > > >
> > > > > Current kexec-tools gets kernel vaddr and size from /proc/kcore. It
> > > > > assumes kernel vaddr start/end is within the range [0,512M). If kaslr
> > > > > enabled, kernel vaddr start/end will stay at [0+offset, 512M+offset).
> > >
> > > NACK this patch myself.
> > >
> > > There are several mistakes I made. I misunderstood some concepts. Then I
> > > realize this kASLR issue is not trivial to fix.
> > >
> > > I think if kexec-tools needs to get kernel text mapping from kcore in
> > > kALSR case, the max base offset (CONFIG_RANDOMIZE_MAX_BASE_OFFSET) of
> > > the kernel text area must be exposed to userspace some where. We can use
> > > that value to determine which area is for kernel text mapping and which
> > > is for modules text mapping.
> >
> > How about looking at /proc/kallsyms and look at address of one of the
> > symbols say _text. And search for the ELF header in kcore which contains
> > _text address and that's ELF header representing kernel text mapping.
>
> Cool. I'd like to go with _stext. _text presents in /proc/kallsyms only
> when CONFIG_KALLSYMS_ALL=y. What do you think?
That's fine. Though looks like _stext will also work only if
CONFIG_KALLSYMS=y. So that's not a perfect solution either for those
who have built kernel using CONFIG_KALLSYMS=n.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-03-20 15:18 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-14 8:20 [PATCH v2] x86, kaslr: Kernel base can be randomized at 0-1G offset WANG Chao
2014-03-17 3:27 ` Dave Young
2014-03-17 12:56 ` Vivek Goyal
2014-03-19 7:05 ` WANG Chao
2014-03-19 13:33 ` Vivek Goyal
2014-03-20 5:46 ` WANG Chao
2014-03-20 15:18 ` Vivek Goyal
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox