linux-kernel - Re: [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside kernel

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:   Thu, 11 Jun 2020 13:47:04 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     ??? <wooy88.kim@...sung.com>
Cc:     'Dave Martin' <Dave.Martin@....com>,
        'Catalin Marinas' <catalin.marinas@....com>,
        'Bhupesh Sharma' <bhsharma@...hat.com>,
        'Julien Grall' <julien.grall@....com>,
        'Vincenzo Frascino' <vincenzo.frascino@....com>,
        'Will Deacon' <will@...nel.org>, yhwan.joo@...sung.com,
        'Anisse Astier' <aastier@...ebox.fr>,
        'Marc Zyngier' <maz@...nel.org>,
        'Allison Randal' <allison@...utok.net>,
        'Sanghoon Lee' <shoon114.lee@...sung.com>,
        jihun.kim@...sung.com, 'Kees Cook' <keescook@...omium.org>,
        'Suzuki K Poulose' <suzuki.poulose@....com>,
        'Wooki Min' <wooki.min@...sung.com>,
        'Kristina Martsenko' <kristina.martsenko@....com>,
        'Jeongtae Park' <jtp.park@...sung.com>,
        'Thomas Gleixner' <tglx@...utronix.de>,
        linux-arm-kernel@...ts.infradead.org,
        'Steve Capper' <steve.capper@....com>,
        'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, 'James Morse' <james.morse@....com>,
        'Sudeep Holla' <sudeep.holla@....com>, dh.han@...sung.com
Subject: Re: [PATCH] arm64: fpsimd: Added API to manage fpsimd state inside
 kernel

On Thu, Jun 11, 2020 at 06:17:32PM +0900, ??? wrote:
> > On Fri, Jun 05, 2020 at 11:37:05AM +0100, Mark Rutland wrote:
> > > Please introduce the problem you are trying to solve in more detail.
> > > We already have kernel_neon_{begin,end}() for kernel-mode NEON; why is
> > > that not sufficient for your needs? Please answer this before
> > > considering other details.
> > >
> > > What do you want to use this for?
> 
> > Ack, this looks supicious.  Can you explain why your usecase _requires_
> > FPSIMD in hardirq context?
> > 
> > For now, these functions are strictly for EFI use only and should never be
> > used by modules.
> 
> I am in charge of camera driver development in Samsung S.LSI division.
> 
> In order to guarantee real time processing
> such as Camera 3A algorithm in current or ongoing projects,
> prebuilt binary is loaded and used in kernel space, rather than user space.
> Because the binary is built with other standard library which could use
> FPSIMD register,
> kernel API should keep the original FPSIMD state for other user tasks.
> It is mostly used for internal kernel operation including hardirq context.
> (ex> hardIRQ context, kernel API called by user, kernel task)

That sounds incredibly dodgy to me, both from a correctness perspective
and a licensing perspective. Upstream doesn't support out-of-tree
modules, nor does upstream support binary blobs within the kernel, so
the above cannot justify this change to the kernel.

If you wish to do such processing within the kernel, I think you'll need
to post a more complete in-tree solution for inclusion in mainline.
However, I suspect that it will be difficult to justify NEON in hardirq
context given preempt rt and friends.

Thanks,
Mark.