Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1421288 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] ARM: mm: fix location of _etext Kees Cook <keescook@chromium.org> - 2016-06-13 22:30 +0200
    Re: [PATCH] ARM: mm: fix location of _etext Russell King - ARM Linux <linux@armlinux.org.uk> - 2016-06-13 23:30 +0200
      Re: [PATCH] ARM: mm: fix location of _etext Kees Cook <keescook@chromium.org> - 2016-06-14 01:20 +0200

#1421288 — Re: [PATCH] ARM: mm: fix location of _etext

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

[toc] | [next] | [standalone]

#1421348

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.

[toc] | [prev] | [next] | [standalone]

#1421442

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web