linux-kernel - Re: [RFC PATCH] arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state

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, 14 Mar 2019 18:07:19 +0000
From:   Julien Grall <julien.grall@....com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Dave Martin <Dave.Martin@....com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-rt-users@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] arm64/fpsimd: Don't disable softirq when touching
 FPSIMD/SVE state

Hi Sebastian,

On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
> On 2019-02-18 15:07:51 [+0000], Julien Grall wrote:
>> Hi,
> Hi,
> 
>>> Wouldn't this arbitrarily increase softirq latency?  Unconditionally
>>> forbidding SIMD in softirq might make more sense.  It depends on how
>>> important the use cases are...
> 
> It would increase the softirq latency but the question is how bad would
> it be. It would continue once the SIMD section is done.

On Arm, the kernel may use either FPSIMD or SVE (if supported by the 
platform). While the FPSIMD context is fairly small (~4K), the SVE 
context can be up to ~64KB.

> If you allow it but made it impossible to use (and use the software
> fallback) then it would slow down the processing. So…

This is a fair point. However, the use of crypto in softirqs seem to be 
limited. So I am wondering whether disabling softirq in all the case is 
worth it.

Would it be possible to consider to forbid/warn about using crypto in 
softirqs?

> 
>> Looking at the commit message from cb84d11e1625 "arm64: neon: Remove support
>> for nested or hardirq kernel-mode NEON", one of the use case for crypto in
>> softirq is certain mac80211 drivers.
>>
>> Is there any other use case for use crypto in softirqs?
> 
> mac80211 does it for some wifi drivers. There used to be IPsec but I
> *think* this moved to the "parallel processing kthread".

I was able to find my way through mac80211 and confirm the use a taslket 
and therefore softirqs. However, I got lost in the ipsec code.

> During my FPU rework on x86 I didn't find anything that does the
> processing in softirq (on my machine) so I hacked something so that I
> could test that I didn't break anything…

This is the same on the platform I have been using for testing.

Cheers,

-- 
Julien Grall