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]
Date:   Mon, 4 Jul 2022 12:00:54 +0200
From:   Heiko Carstens <hca@...ux.ibm.com>
To:     Christian Borntraeger <borntraeger@...ux.ibm.com>
Cc:     Steffen Eiden <seiden@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        Claudio Imbrenda <imbrenda@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, nrb@...ux.ibm.com
Subject: Re: [PATCH 1/2] s390/hwcaps: Add HWCAP_UV

On Fri, Jul 01, 2022 at 12:10:18PM +0200, Christian Borntraeger wrote:
> Am 01.07.22 um 12:02 schrieb Steffen Eiden:
> > This patch adds a hardware capability for the Ultravisor.
> > This capability will be present if facility 158 is enabled.
> > 
> > Signed-off-by: Steffen Eiden <seiden@...ux.ibm.com>
> > ---
> >   arch/s390/include/asm/elf.h  | 2 ++
> >   arch/s390/kernel/processor.c | 5 +++++
> >   2 files changed, 7 insertions(+)
> > 
> > diff --git a/arch/s390/include/asm/elf.h b/arch/s390/include/asm/elf.h
> > index 70a30ae258b7..3a5e89ce4fd0 100644
> > --- a/arch/s390/include/asm/elf.h
> > +++ b/arch/s390/include/asm/elf.h
> > @@ -115,6 +115,7 @@ enum {
> >   	HWCAP_NR_NNPA		= 20,
> >   	HWCAP_NR_PCI_MIO	= 21,
> >   	HWCAP_NR_SIE		= 22,
> > +	HWCAP_NR_UV		= 23,
> >   	HWCAP_NR_MAX
> >   };
> 
> question for Heiko, Vasily, Alexander. This certainly works.
> An alternative implementation would be to separate module_cpu_feature_match
> from HWCAP. (so uv would not be shown in /proc/cpuinfo and it would be
> seen in the aux vector). I would imagine that we might have more drivers
> in the future that depend on a facility but this facility is not really
> useful for userspace to know.
> 
> See arch/s390/include/asm/cpufeature.h
>  * Restrict the set of exposed CPU features to ELF hardware capabilities for
>  * now.  Additional machine flags can be indicated by values larger than
>  * MAX_ELF_HWCAP_FEATURES.
> 
> Any preference from your side?

I mentioned already before this RFC that my preferred solution would
be to have a solution which extends the existing method to work (also)
with facility bits - haven't checked if all existing users could be
converted to facility bits, but making it more flexible would work
certainly.

If Steffen is willing to do that, that would be very welcome.
Otherwise I'll put that on my todo list.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ