lists.openwall.net   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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu-my1pd43WO=A_gQFgvtG3efYD97Fh8P-vG93G9zmPynw@mail.gmail.com>
Date:	Thu, 16 Jun 2016 14:04:48 +0200
From:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:	Kees Cook <keescook@...omium.org>
Cc:	Russell King <linux@...linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	Pratyush Anand <panand@...hat.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Vladimir Murzin <vladimir.murzin@....com>,
	Toshi Kani <toshi.kani@....com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Chris Brandt <chris.brandt@...esas.com>,
	Alexander Potapenko <glider@...gle.com>,
	Marc Zyngier <marc.zyngier@....com>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2] ARM: mm: fix location of _etext

On 15 June 2016 at 22:24, Kees Cook <keescook@...omium.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. Just to be conservative, leave the kernel resource as
> it was, using __init_begin instead of _etext as the end mark.
>
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
> v2:
> - Switched resource tracker to using __init_begin, rmk

Actually, Linus removed the x86 /proc/iomem resources for kernel segments in

c4004b02f8e5 ("x86: remove the kernel code/data/bss resources from /proc/iomem")

so I wonder if we should not just do the same for ARM and arm64?



> ---
>  arch/arm/kernel/setup.c       | 2 +-
>  arch/arm/kernel/vmlinux.lds.S | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 7b5350060612..dd84f03dc2d4 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -844,7 +844,7 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
>         struct resource *res;
>
>         kernel_code.start   = virt_to_phys(_text);
> -       kernel_code.end     = virt_to_phys(_etext - 1);
> +       kernel_code.end     = virt_to_phys(__init_begin - 1);
>         kernel_data.start   = virt_to_phys(_sdata);
>         kernel_data.end     = virt_to_phys(_end - 1);
>
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ