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: <20200225172723.GG4633@sirena.org.uk>
Date:   Tue, 25 Feb 2020 17:27:23 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Amit Kachhap <amit.kachhap@....com>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Paul Elliott <paul.elliott@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Yu-cheng Yu <yu-cheng.yu@...el.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Marc Zyngier <maz@...nel.org>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Szabolcs Nagy <szabolcs.nagy@....com>,
        "H . J . Lu" <hjl.tools@...il.com>,
        Andrew Jones <drjones@...hat.com>,
        Kees Cook <keescook@...omium.org>,
        Arnd Bergmann <arnd@...db.de>, Jann Horn <jannh@...gle.com>,
        Richard Henderson <richard.henderson@...aro.org>,
        Kristina Martšenko <kristina.martsenko@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Florian Weimer <fweimer@...hat.com>,
        Sudakshina Das <sudi.das@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        Dave Martin <Dave.Martin@....com>
Subject: Re: [PATCH v6 05/11] arm64: elf: Enable BTI at exec based on ELF
 program properties

On Tue, Feb 25, 2020 at 06:58:50PM +0530, Amit Kachhap wrote:
> On 2/13/20 12:59 AM, Mark Brown wrote:

> > +static inline int arch_parse_elf_property(u32 type, const void *data,
> > +					  size_t datasz, bool compat,
> > +					  struct arch_elf_state *arch)
> > +{

> Does this check here make sense to skip running extra code?
>     if (!system_supports_bti())
>              return 0;

This specifically is the wrong place for such a test since we didn't
even figure out if we're looking at the BTI property yet so it'd need to
be moved if any further properties are added.

> Although this check is there in arch_validate_prot.

And more importantly in arch_calc_vm_prot_bits() so we never actually
create guarded pages on a system that doesn't support BTI.  That said I
do agree that it seems reasonable to add an explicit check in the
parsing of the actual BTI property for robustness and clarity, I'll do a
patch for that and roll it into any future versions or send it
incrementally if this one is applied but it doesn't seem sensible to
spin the whole series with the very broad CC list it has.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ