linux-kernel - Re: [PATCH RT] arm*: disable NEON in kernel mode

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: <24FDBFF1-8351-46FC-885A-6B6F972F4C6C@linaro.org>
Date:   Fri, 1 Dec 2017 15:03:35 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Mark Rutland <mark.rutland@....com>,
        linux-rt-users@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
        tglx@...utronix.de, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RT] arm*: disable NEON in kernel mode


l
> On 1 Dec 2017, at 14:36, Sebastian Andrzej Siewior <bigeasy@...utronix.de> wrote:
> 
>> On 2017-12-01 14:18:28 [+0000], Mark Rutland wrote:
>> [Adding Ard, who wrote the NEON crypto code]
>> 
>>> On Fri, Dec 01, 2017 at 02:45:06PM +0100, Sebastian Andrzej Siewior wrote:
>>> +arm folks, to let you know
>>> 
>>>> On 2017-12-01 11:43:32 [+0100], To linux-rt-users@...r.kernel.org wrote:
>>>> NEON in kernel mode is used by the crypto algorithms and raid6 code.
>>>> While the raid6 code looks okay, the crypto algorithms do not: NEON
>>>> is enabled on first invocation and may allocate/free/map memory before
>>>> the NEON mode is disabled again.
>> 
>> Could you elaborate on why this is a problem?
>> 
>> I guess this is because kernel_neon_{begin,end}() disable preemption?
>> 
>> ... is this specific to RT?
> 
> It is RT specific, yes. One thing are the unbounded latencies since
> everything in this preempt_disable section can take time depending on
> the size of the request.
> The other thing is code like in
>  arch/arm64/crypto/aes-ce-ccm-glue.c:ccm_encrypt()
> 
> where within this preempt_disable() section skcipher_walk_done() is
> invoked. That function can allocate/free/map memory which is okay for
> !RT but is not for RT. I tried to break those loops for x86 [0] and I
> simply didn't had the time to do the same for ARM. I am aware that
> store/restore of the NEON registers (as SSE and AVX) is expensive and
> doing a lot of operations in one go is desired.

I wouldn’t mind fixing the code instead. We never disable the neon, but only stack the contents of the registers the first time, and unstack them only before returning to userland (with the exception of nested neon use in softirq context). When this code was introduced, we always stacked/unstacked the whole register file eagerly every time.


> So for x86 I would want
> to do some benchmarks and come up with some numbers based on which I
> can argue with people one way or another depending on how much it hurts
> and how long preemption can be disabled.
> 
> [0] https://www.spinics.net/lists/kernel/msg2663115.html
> 
>> Thanks,
>> Mark.
> 
> Sebastian