lkml.org 
[lkml]   [2022]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v4 10/24] crypto: x86/poly - limit FPU preemption
    Date

    On Fri, Nov 25, 2022 at 09:59:17AM +0100, Ard Biesheuvel wrote:
    > On arm64, this is implemented in an assembler macro 'cond_yield' so we
    > don't need to preserve/restore the SIMD state state at all if the
    > yield is not going to result in a call to schedule(). For example, the
    > SHA3 code keeps 400 bytes of state in registers, which we don't want
    > to save and reload unless needed. (5f6cb2e617681 'crypto:
    > arm64/sha512-ce - simplify NEON yield')

    That sounds like the optimal approach. There is a cost to unnecessary
    kernel_fpu_begin()/end() calls - increasing their usage in the x86
    sha512 driver added 929 us during one boot. The cond_yield check is
    just a few memory reads and conditional branches.

    I see that is built on the asm-offsets.c technique mentioned by
    Dave Hansen in the x86 aria driver thread.

    > Note that it is only used in shash implementations, given that they
    > are the only ones that may receive unbounded inputs.

    Although typical usage probably doesn't stress this, the length of the
    additional associated data presented to aead implementations is
    unconstrained as well. At least in x86, they can end up processing
    multiple megabytes in one chunk like the hash functions (if the
    associated data is a big buffer described by a sg list created
    with sg_init_one()).


    \
     
     \ /
      Last update: 2022-11-28 17:59    [W:4.567 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site