netdev - Re: [RFC PATCH 0/5] IPsec parallelization

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: <20081202081948.GA30063@gondor.apana.org.au>
Date:	Tue, 2 Dec 2008 16:19:48 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Steffen Klassert <steffen.klassert@...unet.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	klassert@...hematik.tu-chemnitz.de
Subject: Re: [RFC PATCH 0/5] IPsec parallelization

On Tue, Dec 02, 2008 at 08:58:04AM +0100, Steffen Klassert wrote:
> 
> The parallelization/serialization interface is generic, so the crypto
> layer can use it in the same way as xfrm.

I don't really have an opinion on the padata stuff.  What I'm
objecting to is the way you're putting the parallelism into
xfrm.

> The only network specific information that is used is the knowledge
> of the xfrm_state that a packet uses. On serialization, this helps
> to stay as parallel as possible. Packets that uses the same state must
> go to the same cpu (because of the replay window) packets that use
> different states can go to different cpus.

Maybe I'm missing somthing, but all you're doing is paralleising
based on xfrm_state objects.  You can already do that trivially
in the crypto layer with no network-specific knowledge at all
because each xfrm_state allocates its own tfm objects.

What I'm proposing is that you create a single parallel crypto
algorithm template similar to cryptd (FWIW you could even just
extend cryptd to do this) that does the parallel processing
based on tfms.

This achieves exactly the same thing as your current patch-set
plus:

1) The uesr no longer has to make a system-wide choice of whether
to enable this, instead the control is per-SA through the usual
algorithm selection mechanism which means that this no longer
conflicts with async crypto;

2) There is no change to the xfrm code;

3) The same mechanism can benefit other crypto users such as
disk encryption.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html