linux-kernel - Re: [RFC PATCH 01/10] arm64: feature registers: Documentation

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: <20150811142301.GE23307@e104818-lin.cambridge.arm.com>
Date:	Tue, 11 Aug 2015 15:23:01 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:	"Suzuki K. Poulose" <Suzuki.Poulose@....com>,
	Mark Rutland <Mark.Rutland@....com>,
	"aph@...hat.com" <aph@...hat.com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"edward.nevill@...aro.org" <edward.nevill@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 01/10] arm64: feature registers: Documentation

On Mon, Aug 10, 2015 at 07:48:48PM +0200, Ard Biesheuvel wrote:
> > On 10/08/15 17:06, Catalin Marinas wrote:
> >> And to debunk some of the counter arguments:
> >>
> >> a) Running out of HWCAP bits - I really doubt this, we can always
> >>     introduce 64 more via a new elf_hwcapX
> 
> Note that ELF_HWCAP is also wired into ifunc resolution of GNU
> indirect functions, which looks like a useful feature although it
> isn't used that widely yet.

I forgot to mention, we also need an HWCAP_CPUID with these patches when
we expose the MRS interface. The ifunc resolver could use MRS when
available. But I would still keep adding HWCAP bits for new features,
even if we risk running out of the 64-bit we have now.

> The ifunc prototype for aarch64 has only one 'long' parameter, and I
> don't know if it is possible to extend that without having a bit in
> HWCAPn to indicate that HWCAPn+1 is valid. Also, the ifunc resolvers
> are restricted in the sense that they cannot use shared libraries or
> code that uses constructors (AFAIR) so it may require a special static
> library to call this CPU feature interface from such a resolver if
> features are not covered by HWCAP bits.

Or we could get some compiler intrinsics that generate the instruction
inline, just to avoid explicit asm.

> So treating HWCAP bits as an endless supply may not be the wisest
> approach here.

Probably not for ifunc, otherwise I don't think it hurts.

> Also, I think some alignment with the libc folks is indeed in order.

I agree (not sure how they feel about cross-posting though).

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/