netdev - Re: [PATCH net] net: macsec: preserve ingress frame ordering

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:   Mon, 27 Apr 2020 11:12:27 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     scott@...ttdial.com
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net] net: macsec: preserve ingress frame ordering

From: Scott Dial <scott@...ttdial.com>
Date: Fri, 24 Apr 2020 18:51:08 -0400

> While it's presumable that the pure AES-NI version of gcm(aes)
> is more performant, the hybrid solution is capable of gigabit
> speeds on modest hardware. Regardless, preserving the order
> of frames is paramount for many network protocols (e.g.,
> triggering TCP retries). Within the MACsec driver itself, the
> replay protection is tripped by the out-of-order frames, and
> can cause frames to be dropped.

It's a real shame that instead of somehow fixing the most performant
setup to be actually usable, we are just throwing our hands up in
the air and simply avoiding to use it.

I feel _really_ bad for the person trying to figure out why they
aren't getting the macsec performance they expect, scratching their
heads for hours trying to figure out why the AES-NI x86 code isn't
being used, and after days finding a commit like this.

> -	tfm = crypto_alloc_aead("gcm(aes)", 0, 0);
> +	/* Pick a sync gcm(aes) cipher to ensure order is preserved. */
> +	tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);

How does this mask argument passed to crypto_alloc_aead() work?  You
are specifying async, does this mean you're asking for async or
non-async?