[PATCH] ARM: mm: fix location of _etext

[PATCH] ARM: mm: fix location of _etext

[Kees Cook]

The _etext position is defined to be the end of the kernel text code,
and should not include any part of the data segments. This interferes
with things that might check memory ranges and expect executable code
up to _etext.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
arm64 needs this fixed too, but it has other assumptions built onto
_etext that should be using different markers.
---
 arch/arm/kernel/vmlinux.lds.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index e2c6da096cef..99420fc1f066 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -125,6 +125,8 @@ SECTIONS
 #ifdef CONFIG_DEBUG_ALIGN_RODATA
 	. = ALIGN(1<<SECTION_SHIFT);
 #endif
+	_etext = .;			/* End of text section */
+
 	RO_DATA(PAGE_SIZE)
 
 	. = ALIGN(4);
@@ -155,8 +157,6 @@ SECTIONS
 
 	NOTES
 
-	_etext = .;			/* End of text and rodata section */
-
 #ifdef CONFIG_DEBUG_RODATA
 	. = ALIGN(1<<SECTION_SHIFT);
 #else
-- 
2.7.4


-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH] ARM: mm: fix location of _etext

[Kees Cook]

On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook <keescook@chromium.org> wrote:
> The _etext position is defined to be the end of the kernel text code,
> and should not include any part of the data segments. This interferes
> with things that might check memory ranges and expect executable code
> up to _etext.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>

Can someone give this an Ack? I'd like to land it as it is a
prerequisite to some usercopy hardening work I'm doing.

Thanks!

-Kees

> ---
> arm64 needs this fixed too, but it has other assumptions built onto
> _etext that should be using different markers.
> ---
>  arch/arm/kernel/vmlinux.lds.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index e2c6da096cef..99420fc1f066 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -125,6 +125,8 @@ SECTIONS
>  #ifdef CONFIG_DEBUG_ALIGN_RODATA
>         . = ALIGN(1<<SECTION_SHIFT);
>  #endif
> +       _etext = .;                     /* End of text section */
> +
>         RO_DATA(PAGE_SIZE)
>
>         . = ALIGN(4);
> @@ -155,8 +157,6 @@ SECTIONS
>
>         NOTES
>
> -       _etext = .;                     /* End of text and rodata section */
> -
>  #ifdef CONFIG_DEBUG_RODATA
>         . = ALIGN(1<<SECTION_SHIFT);
>  #else
> --
> 2.7.4
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [PATCH] ARM: mm: fix location of _etext

[Russell King - ARM Linux]

On Mon, Jun 13, 2016 at 01:23:29PM -0700, Kees Cook wrote:
> On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook <keescook@chromium.org> wrote:
> > The _etext position is defined to be the end of the kernel text code,
> > and should not include any part of the data segments. This interferes
> > with things that might check memory ranges and expect executable code
> > up to _etext.
> >
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> 
> Can someone give this an Ack? I'd like to land it as it is a
> prerequisite to some usercopy hardening work I'm doing.

We use _etext to place the end of the "kernel code" resource in
/proc/iomem, and init_mm.end_code.  I don't think anything makes
use of init_mm.end_code, but I'm more worried about the resource.

Currently, because of where _etext is placed, "kernel code" covers
the read-only data and other read-only sections as well - I don't
know whether we need to preserve that, but this change has a side
effect of changing that.

Maybe we also need a "kernel rodata" resource?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] ARM: mm: fix location of _etext

[Kees Cook]

On Mon, Jun 13, 2016 at 2:25 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Mon, Jun 13, 2016 at 01:23:29PM -0700, Kees Cook wrote:
>> On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook <keescook@chromium.org> wrote:
>> > The _etext position is defined to be the end of the kernel text code,
>> > and should not include any part of the data segments. This interferes
>> > with things that might check memory ranges and expect executable code
>> > up to _etext.
>> >
>> > Signed-off-by: Kees Cook <keescook@chromium.org>
>>
>> Can someone give this an Ack? I'd like to land it as it is a
>> prerequisite to some usercopy hardening work I'm doing.
>
> We use _etext to place the end of the "kernel code" resource in
> /proc/iomem, and init_mm.end_code.  I don't think anything makes
> use of init_mm.end_code, but I'm more worried about the resource.

Yeah, I looked at the init_mm.end_code thing and it appears to be
entirely aesthetics. The kernel code resource in /proc/iomem is
correct to end at the end of the kernel (this is what all other
architectures have too). That resource is used by kexec, and shouldn't
care about losing non-executable memory regions.

> Currently, because of where _etext is placed, "kernel code" covers
> the read-only data and other read-only sections as well - I don't
> know whether we need to preserve that, but this change has a side
> effect of changing that.

include/asm-generic/vmlinux.lds.h documents the expected underscore
names (and things like mem_init_print_info() operate on them. (Also of
note is that _sdata through _edata is supposed to cover both ro and rw
data, which isn't true for ARM, but isn't causing problems.
mem_init_print_info() handles overlaps/embedded areas, but things like
core_kernel_text() don't expect non-executable code in _stext through
_etext).

>
> Maybe we also need a "kernel rodata" resource?

This is already tracked with the standard markers of __start_rodata
and __end_rodata.

If you want to be extra cautious, we could change kernel_code.end to
be __init_begin - 1, maybe?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security