linux-kernel - Re: [PATCH] ARM: bcmbca: add VFP and NEON fixup for bcm6846 SoC

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YqohjUuJ7ivSFeMN@shell.armlinux.org.uk>
Date:   Wed, 15 Jun 2022 19:14:37 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     William Zhang <william.zhang@...adcom.com>,
        Linux ARM List <linux-arm-kernel@...ts.infradead.org>,
        joel.peshkin@...adcom.com, dan.beygelman@...adcom.com,
        anand.gore@...adcom.com, kursad.oney@...adcom.com,
        samyon.furman@...adcom.com, tomer.yacoby@...adcom.com,
        philippe.reynes@...tathome.com,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Ray Jui <rjui@...adcom.com>,
        Scott Branden <sbranden@...adcom.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: bcmbca: add VFP and NEON fixup for bcm6846 SoC

On Wed, Jun 15, 2022 at 10:43:28AM -0700, Florian Fainelli wrote:
> On 5/24/22 17:35, William Zhang wrote:
> > BCM6846 SoC only has VFP and NEON support on core 0. So kernel VPF/NEON
> > support is disabled in this chip. Add this fixup to manually turn on
> > VFP/NEON in case userspace app need to access them on core 0.
> > 
> > Signed-off-by: William Zhang <william.zhang@...adcom.com>
> 
> We have had this conversation internally already, but I do not think this is
> sufficient in order to have a workable solution, you indicated that there is
> all sorts of user-space involvement in your SDK to ensure that only VFP
> tasks are scheduled on core 0, but if we were to seek a proper solution we
> would have to modify the ARM Linux kernel to forcibly migrate VFP tasks onto
> a core that can support executing them, or accept emulating them with the
> implied slow down.
> 
> Russell, what are your thoughts on this?

The patch only enables access to the VFP, which adds the additional
instructions on that core. However, if the kernel has decided that
VFP isn't available, then we won't be advertising VFP via the HWCAPS
and therefore libraries won't be using it.

However, there may be some userspace that "probes" for VFP instruction
presence by trying to execute a VFP instruction, and catching the
SIGILL. The problem here is if we enable it on core 0 and such an app
is used, then it will think VFP is generally available when it isn't.

So, in terms of system stability, I don't think this is something we
want to generally do.

Also, without the VFP kernel support code, VFP registers won't be
saved and restored across context switches (which makes them a nice
path for covert communication) and neither will they be saved and
restored properly for signal handlers - so any use of VFP on that
core would need to be carefully thought through.

It doesn't sound like a particularly good idea for a generic kernel
to me, even one running on the specific hardware. For example, a
debian hardfp userspace may well run on core 0 but not properly.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!