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: <alpine.DEB.2.21.2411131542500.9262@angie.orcam.me.uk>
Date: Wed, 13 Nov 2024 15:55:26 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Rong Xu <xur@...gle.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Masahiro Yamada <masahiroy@...nel.org>, 
    Nick Desaulniers <ndesaulniers@...gle.com>, 
    Klara Modin <klarasmodin@...il.com>, linux-mips@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] MIPS: move _stext definition to vmlinux.lds.S

On Tue, 12 Nov 2024, Rong Xu wrote:

> The _stext symbol is intended to reference the start of the text section.
> However, it currently relies on a fragile link order because the existing
> EXPORT(_stext) resides within the .text section, which is not guaranteed
> to be placed first.

 Umm, arch/mips/kernel/head.S does mean to be linked first.  We rely on it 
for environments where there's no entry point is available and execution 
starts from the beginning of the image.  See the comment right below your 
change.

> Move the _stext definition to the linker script to enforce an explicit
> ordering.

 So if you say that the link order is fragile (which it may well be), then 
that problem has to be fixed instead, likely with the linker script too, 
and then perhaps an ASSERT placed there to verify that it has worked and 
`_stext' refers to the beginning, taking into account what follows too.

 Also note that `_stext' currently points beyond the space reserved for
exception handlers.  Have you analysed what the consequences would be if 
it was moved ahead of it, which your change does AFAICT?

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ