* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-09-01 7:28 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <20160901071958.GA2076@gondor.apana.org.au>
On 01/09/16 10:19, Herbert Xu wrote:
> On Thu, Sep 01, 2016 at 09:56:06AM +0300, Tero Kristo wrote:
>>
>> Hmm, looking at the driver, sham_update returns 0 immediately if it
>> just caches data. In a sense, the update is not completed at this
>> point. Are you saying this is illegal and can't be done?
>
> Once you call the completion function (and returning zero from
> the update itself is equivalent to calling the completion function)
> the hardware must not touch the request anymore.
Yeah, it is not touching it anymore. All the data has been copied to the
local buffer at this point, and the driver isn't retaining any kind of a
handle to the request itself anymore. It is just that it has not been
processed by the hardware yet.
>
>> From my understanding, valid results are expected from the driver
>> only after ->final is called.
>
> That's because you never implemented export/import :)
Yeah, the flush should do the trick now. Kind of a chicken-egg problem
here. :P How do you see the situation with the above explanation?
-Tero
^ permalink raw reply
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Herbert Xu @ 2016-09-01 7:19 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <70468d4d-9f26-1bad-ace1-4b7c5cf43b52@ti.com>
On Thu, Sep 01, 2016 at 09:56:06AM +0300, Tero Kristo wrote:
>
> Hmm, looking at the driver, sham_update returns 0 immediately if it
> just caches data. In a sense, the update is not completed at this
> point. Are you saying this is illegal and can't be done?
Once you call the completion function (and returning zero from
the update itself is equivalent to calling the completion function)
the hardware must not touch the request anymore.
> From my understanding, valid results are expected from the driver
> only after ->final is called.
That's because you never implemented export/import :)
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: hwrng: pasemi_rng.c: Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-09-01 6:59 UTC (permalink / raw)
To: Darren Stevens
Cc: Herbert Xu, linux-kernel, LABBE Corentin, linux-crypto, mpm, olof,
linuxppc-dev
In-Reply-To: <48bab268a61.66716f37@auth.smtp.1and1.co.uk>
> I didn't explain well, There is a CFE command 'show devtree' here's the
> relevant bits (I Hope)
This is much simple than I expected.
> [CFE ]CFE> show devtree
> [/]
> | #interrupt-cells val 0x00000002
> | #address-cells val 0x00000002
> | #size-cells val 0x00000002
>
> ...[snip]...
>
> [sdc@fc000000]
> | name str 'sdc'
> | device_type str 'sdc'
> | #address-cells val 0x00000001
> | #size-cells val 0x00000001
> | compatible str '1682m-sdc' 'pasemi,pwrficient-sdc'
> 'pasemi,sdc'
> | reg cell 00000000 FC000000 00000000 00800000
>
> ...[snip]...
>
> [rng@fc105000]
> | name str 'rng'
> | device_type str 'rng'
> | compatible str '1682m-rng' 'pasemi,pwrficient-rng'
> 'pasemi,rng'
> | reg cell FC105000 00001000
>
Device tree provided by CFE has the size. I will send another patch
which uses devm_ioremap_resource().
Appreciate your help. Thank you :).
^ permalink raw reply
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-09-01 6:56 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <20160901061630.GB650@gondor.apana.org.au>
On 01/09/16 09:16, Herbert Xu wrote:
> On Thu, Sep 01, 2016 at 09:12:59AM +0300, Tero Kristo wrote:
>>
>> Well, but the driver doesn't flush its buffers automatically, it
>> caches data until it has sufficient amount available. So, assuming
>> you want to do this:
>>
>> sham_init
>> sham_update 256 bytes
>> sham_update 256 bytes
>> wait until two above updates are complete
>> sham_export
>>
>> ... the execution hangs at the wait phase as the driver is still
>
> Well that's a bug in the driver. While it's not illegal to wait
> for more data, it's usually unnecessary. Because we instead try
> to get our users to generate as big a request as possible, e.g.,
> one packet for IPsec.
>
> If you really have to do the hold thing, then you must install a
> timer like sha1-mb does on x86 to do the flush.
>
> In any case, the completion function must not be called until
> you're actually complete.
Hmm, looking at the driver, sham_update returns 0 immediately if it just
caches data. In a sense, the update is not completed at this point. Are
you saying this is illegal and can't be done?
From my understanding, valid results are expected from the driver only
after ->final is called.
-Tero
^ permalink raw reply
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Herbert Xu @ 2016-09-01 6:16 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <60a5ed40-5552-3ec8-fa21-7e6fb8213fc3@ti.com>
On Thu, Sep 01, 2016 at 09:12:59AM +0300, Tero Kristo wrote:
>
> Well, but the driver doesn't flush its buffers automatically, it
> caches data until it has sufficient amount available. So, assuming
> you want to do this:
>
> sham_init
> sham_update 256 bytes
> sham_update 256 bytes
> wait until two above updates are complete
> sham_export
>
> ... the execution hangs at the wait phase as the driver is still
Well that's a bug in the driver. While it's not illegal to wait
for more data, it's usually unnecessary. Because we instead try
to get our users to generate as big a request as possible, e.g.,
one packet for IPsec.
If you really have to do the hold thing, then you must install a
timer like sha1-mb does on x86 to do the flush.
In any case, the completion function must not be called until
you're actually complete.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-09-01 6:12 UTC (permalink / raw)
To: Herbert Xu
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <20160901033320.GA650@gondor.apana.org.au>
On 01/09/16 06:33, Herbert Xu wrote:
> On Mon, Aug 29, 2016 at 05:11:35PM +0300, Tero Kristo wrote:
>>
>>>> +static int omap_sham_export(struct ahash_request *req, void *out)
>>>> +{
>>>> + struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
>>>> +
>>>> + while (omap_sham_flush(req) == -EINPROGRESS)
>>>> + msleep(10);
>>>
>>> Do we really need this? You must not call export until the previous
>>> operation has completed.
>>>
>>> Cheers,
>>>
>>
>> Sorry about a late reply, I was out on vacation.
>>
>> For OMAP SHAM, this is actually needed, because the driver still has
>> a very large internal buffer for performance reasons, and the whole
>> buffer can't be exported. The flush functionality pushes out
>> sufficient amount of data to the hardware, so that the rest of the
>> buffer can be exported to the available space.
>
> It doesn't matter whether you have a buffer or not. The point
> is that the completion function should not be called until the
> operation is actually complete. This is the whole point of the
> async interface.
>
> As the user must not call export until the completion function
> has been called, there should be no need to wait in the export
> function.
Well, but the driver doesn't flush its buffers automatically, it caches
data until it has sufficient amount available. So, assuming you want to
do this:
sham_init
sham_update 256 bytes
sham_update 256 bytes
wait until two above updates are complete
sham_export
... the execution hangs at the wait phase as the driver is still waiting
for more data to cache, and will never complete the two update requests.
Currently, the driver is written in such way that it waits until it has
enough data cached before starting to push it out to hardware, or waits
until sham_final to be called. Pushing out small pieces of data causes
severe performance degradation on the driver, as setting up the DMA
operation itself is rather costly.
Either way, flush for the buffers is needed, I wonder if automatic flush
should be added also based on some timer.
-Tero
^ permalink raw reply
* Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Herbert Xu @ 2016-09-01 3:33 UTC (permalink / raw)
To: Tero Kristo
Cc: lokeshvutla, davem, linux-crypto, tony, linux-omap,
linux-arm-kernel
In-Reply-To: <d828fca9-a97a-7722-c4cb-24e07816cbc4@ti.com>
On Mon, Aug 29, 2016 at 05:11:35PM +0300, Tero Kristo wrote:
>
> >>+static int omap_sham_export(struct ahash_request *req, void *out)
> >>+{
> >>+ struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
> >>+
> >>+ while (omap_sham_flush(req) == -EINPROGRESS)
> >>+ msleep(10);
> >
> >Do we really need this? You must not call export until the previous
> >operation has completed.
> >
> >Cheers,
> >
>
> Sorry about a late reply, I was out on vacation.
>
> For OMAP SHAM, this is actually needed, because the driver still has
> a very large internal buffer for performance reasons, and the whole
> buffer can't be exported. The flush functionality pushes out
> sufficient amount of data to the hardware, so that the rest of the
> buffer can be exported to the available space.
It doesn't matter whether you have a buffer or not. The point
is that the completion function should not be called until the
operation is actually complete. This is the whole point of the
async interface.
As the user must not call export until the completion function
has been called, there should be no need to wait in the export
function.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: CONFIG_FIPS without module loading support?
From: Stephan Mueller @ 2016-09-01 1:49 UTC (permalink / raw)
To: NTU; +Cc: linux-crypto
In-Reply-To: <CAM5Ud7MDpZyTrcQ2NtghG6cGT8qfGfP6zYw+vJDQrHqFHor6sg@mail.gmail.com>
Am Mittwoch, 31. August 2016, 20:32:42 CEST schrieb NTU:
Hi NTU,
> Hello,
>
> CRYPTO_FIPS depends on MODULE_SIG and I understand why it would as you
> wouldn't want unsigned modules from external sources being loaded. If
> CONFIG_MODULES is disabled though (no module loading) there are no
> modules to sign in the first place.
>
> Wouldn't it make more sense for CONFIG_FIPS to depend on (MODULE_SIG
> [=y] && CONFIG_MODULES [y]) ?
>
> Thank you!
Yes, that is correct.
>
> Alec Ari
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
^ permalink raw reply
* CONFIG_FIPS without module loading support?
From: NTU @ 2016-09-01 1:32 UTC (permalink / raw)
To: linux-crypto
Hello,
CRYPTO_FIPS depends on MODULE_SIG and I understand why it would as you
wouldn't want unsigned modules from external sources being loaded. If
CONFIG_MODULES is disabled though (no module loading) there are no
modules to sign in the first place.
Wouldn't it make more sense for CONFIG_FIPS to depend on (MODULE_SIG
[=y] && CONFIG_MODULES [y]) ?
Thank you!
Alec Ari
^ permalink raw reply
* Dear Sir/Madam
From: John williams @ 2016-08-31 19:14 UTC (permalink / raw)
--
Dear Sir/Madam, we would like to see your company latest catalogs.
Your early reply is highly appreciated.
Thank You !
Best Regards,
Mr. John williams
(Purchasing Manager)
*****************************************************
Trade Company limited.
2755 lake pine path apt 122,
St Joseph, Trade Square Centre MI United States
Telephone: +1 (248) 854 5480
E-mail: william-john92@hotmail.com
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix constants table DMA
From: Herbert Xu @ 2016-08-31 15:19 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, Maksim Lukoshkov
In-Reply-To: <1472473711-611-1-git-send-email-giovanni.cabiddu@intel.com>
On Mon, Aug 29, 2016 at 01:28:31PM +0100, Giovanni Cabiddu wrote:
> From: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
>
> Copy const_tab array into DMA-able memory (accesible by qat hw).
>
> Signed-off-by: Maksim Lukoshkov <maksim.lukoshkov@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3] crypto: caam - fix IV loading for authenc (giv)decryption
From: Herbert Xu @ 2016-08-31 15:19 UTC (permalink / raw)
To: Horia Geantă; +Cc: linux-crypto, David S. Miller
In-Reply-To: <1472471534-9544-1-git-send-email-horia.geanta@nxp.com>
On Mon, Aug 29, 2016 at 02:52:14PM +0300, Horia Geantă wrote:
> For algorithms that implement IV generators before the crypto ops,
> the IV needed for decryption is initially located in req->src
> scatterlist, not in req->iv.
>
> Avoid copying the IV into req->iv by modifying the (givdecrypt)
> descriptors to load it directly from req->src.
> aead_givdecrypt() is no longer needed and goes away.
>
> Cc: <stable@vger.kernel.org> # 4.3+
> Fixes: 479bcc7c5b9e ("crypto: caam - Convert authenc to new AEAD interface")
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] Use devm_hwrng_register instead of hwrng_register
From: Herbert Xu @ 2016-08-31 15:19 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, linux-crypto
In-Reply-To: <1472374152-19319-1-git-send-email-prasannatsmkumar@gmail.com>
On Sun, Aug 28, 2016 at 02:19:12PM +0530, PrasannaKumar Muralidharan wrote:
> By using devm_hwrng_register instead of hwrng_register the .remove
> callback in platform_driver can be removed. This reduces a few lines in
> code.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hw_random: Remove check for max less than 4 bytes
From: Herbert Xu @ 2016-08-31 15:18 UTC (permalink / raw)
To: PrasannaKumar Muralidharan; +Cc: mpm, linux-crypto, linux-kernel
In-Reply-To: <1472236324-7067-1-git-send-email-prasannatsmkumar@gmail.com>
On Sat, Aug 27, 2016 at 12:02:04AM +0530, PrasannaKumar Muralidharan wrote:
> HW RNG core never asks for data less than 4 bytes. The check whether max
> is less than 4 bytes is unnecessary. Remove the check.
>
> Signed-off-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] fix:caam:ctrl:add missing header dependencies
From: Herbert Xu @ 2016-08-31 15:18 UTC (permalink / raw)
To: Baoyou Xie
Cc: davem, arnd, tudor-dan.ambarus, linux-crypto, linux-kernel,
xie.baoyou
In-Reply-To: <1472205384-29888-1-git-send-email-baoyou.xie@linaro.org>
On Fri, Aug 26, 2016 at 05:56:24PM +0800, Baoyou Xie wrote:
> We get 1 warning when biuld kernel with W=1:
> drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for 'caam_get_era' [-Wmissing-prototypes]
>
> In fact, this function is declared in drivers/crypto/caam/ctrl.h,
> so this patch add missing header dependencies.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 0/8] hwrng: amd: rework of the amd hwrng driver
From: Herbert Xu @ 2016-08-31 15:18 UTC (permalink / raw)
To: LABBE Corentin; +Cc: mpm, linux-crypto, linux-kernel
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>
On Fri, Aug 26, 2016 at 01:11:28PM +0200, LABBE Corentin wrote:
> Changes since v2:
> - split the latest patch in 4
> Changes since v1:
> - Keep the hwrng name as "amd"
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: FIPS - allow tests to be disabled in FIPS mode
From: Herbert Xu @ 2016-08-31 15:18 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto, Tapas Sarangi
In-Reply-To: <1685622.m1phZymvbe@positron.chronox.de>
On Thu, Aug 25, 2016 at 03:15:01PM +0200, Stephan Mueller wrote:
> In FIPS mode, additional restrictions may apply. If these restrictions
> are violated, the kernel will panic(). This patch allows test vectors
> for symmetric ciphers to be marked as to be skipped in FIPS mode.
>
> Together with the patch, the XTS test vectors where the AES key is
> identical to the tweak key is disabled in FIPS mode. This test vector
> violates the FIPS requirement that both keys must be different.
>
> Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/2] HWRNG/PCI: Add driver for Cavium Thunder RNG
From: Herbert Xu @ 2016-08-31 15:17 UTC (permalink / raw)
To: Omer Khaliq
Cc: linux-kernel, linux-pci, linux-crypto, linux-arm-kernel, bhelgaas,
mpm, Ananth.Jasty, David.Daney, clabbe.montjoie
In-Reply-To: <1471994835-2423-1-git-send-email-okhaliq@caviumnetworks.com>
On Tue, Aug 23, 2016 at 04:27:13PM -0700, Omer Khaliq wrote:
> There is a hardware error rendering the FDL field incorrect for the some
> Thunder RNG devices. The first patch adds a PCI quirk to fix the problem.
>
> The second patch adds the driver.
>
> Changes from v1:
> Use PCI quirks as advised.
> Removed unecessary headers
> Format changes as advised
All applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: hide unused label
From: Arnd Bergmann @ 2016-08-31 14:43 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, Martin Schwidefsky, linux-crypto, linux-kernel
In-Reply-To: <20160831143752.GA26616@gondor.apana.org.au>
On Wednesday, August 31, 2016 10:37:52 PM CEST Herbert Xu wrote:
> On Mon, Aug 29, 2016 at 02:40:43PM +0200, Arnd Bergmann wrote:
> > A recent change left an existing label unused in some configurations,
> > as seen from a gcc warning:
> >
> > crypto/xor.c: In function 'calibrate_xor_blocks':
> > crypto/xor.c:156:1: error: label 'out' defined but not used [-Werror=unused-label]
> >
> > This adds an #ifdef around it to match the one around the respective "goto".
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Fixes: 39457acda913 ("crypto: xor - skip speed test if the xor function is selected automatically")
>
> Thanks for the patch. But I've already queued up a fix at
>
> https://patchwork.kernel.org/patch/9301603/
>
Ok, that one looks like a nicer solution anyway.
Arnd
^ permalink raw reply
* Re: [PATCH 1/2] crypto: arm/ghash-ce - add missing async import/export
From: Herbert Xu @ 2016-08-31 14:41 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-crypto
In-Reply-To: <1472469594-27315-1-git-send-email-ard.biesheuvel@linaro.org>
On Mon, Aug 29, 2016 at 12:19:53PM +0100, Ard Biesheuvel wrote:
> Since commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero"),
> all ahash drivers are required to implement import()/export(), and must have
> a non-zero statesize. Fix this for the ARM Crypto Extensions GHASH
> implementation.
>
> Fixes: 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/crypto/ghash-ce-glue.c | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm/crypto/ghash-ce-glue.c b/arch/arm/crypto/ghash-ce-glue.c
> index 1568cb5cd870..212aaa715fdb 100644
> --- a/arch/arm/crypto/ghash-ce-glue.c
> +++ b/arch/arm/crypto/ghash-ce-glue.c
> @@ -220,6 +220,29 @@ static int ghash_async_digest(struct ahash_request *req)
> }
> }
>
> +static int ghash_async_import(struct ahash_request *req, const void *in)
> +{
> + struct ahash_request *cryptd_req = ahash_request_ctx(req);
> + struct shash_desc *desc = cryptd_shash_desc(cryptd_req);
> + struct ghash_desc_ctx *dctx = shash_desc_ctx(desc);
> +
> + ghash_async_init(req);
Is this really needed?
> + *dctx = *(const struct ghash_desc_ctx *)in;
I'd prefer to call the underlying shash import/export functions
like we do in cryptd.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] crypto: hide unused label
From: Herbert Xu @ 2016-08-31 14:37 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Martin Schwidefsky, linux-crypto, linux-kernel
In-Reply-To: <20160829124050.3405624-1-arnd@arndb.de>
On Mon, Aug 29, 2016 at 02:40:43PM +0200, Arnd Bergmann wrote:
> A recent change left an existing label unused in some configurations,
> as seen from a gcc warning:
>
> crypto/xor.c: In function 'calibrate_xor_blocks':
> crypto/xor.c:156:1: error: label 'out' defined but not used [-Werror=unused-label]
>
> This adds an #ifdef around it to match the one around the respective "goto".
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 39457acda913 ("crypto: xor - skip speed test if the xor function is selected automatically")
Thanks for the patch. But I've already queued up a fix at
https://patchwork.kernel.org/patch/9301603/
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: caam - fix rfc3686(ctr(aes)) IV load
From: Catalin Vasile @ 2016-08-31 12:57 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, davem, horia.geanta, Catalin Vasile
-nonce is being loaded using append_load_imm_u32() instead of
append_load_as_imm() (nonce is a byte array / stream, not a 4-byte
variable)
-counter is not being added in big endian format, as mandatated by
RFC3686 and expected by the crypto engine
Signed-off-by: Catalin Vasile <cata.vasile@nxp.com>
Reviewed-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/caamalg.c | 82 +++++++++++++++++++--------------------
drivers/crypto/caam/desc_constr.h | 17 ++++++++
2 files changed, 57 insertions(+), 42 deletions(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 6dc5971..f1116e7 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -227,8 +227,9 @@ static void append_key_aead(u32 *desc, struct caam_ctx *ctx,
if (is_rfc3686) {
nonce = (u32 *)((void *)ctx->key + ctx->split_key_pad_len +
enckeylen);
- append_load_imm_u32(desc, *nonce, LDST_CLASS_IND_CCB |
- LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
+ append_load_as_imm(desc, nonce, CTR_RFC3686_NONCE_SIZE,
+ LDST_CLASS_IND_CCB |
+ LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
append_move(desc,
MOVE_SRC_OUTFIFO |
MOVE_DEST_CLASS1CTX |
@@ -500,11 +501,10 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
/* Load Counter into CONTEXT1 reg */
if (is_rfc3686)
- append_load_imm_u32(desc, be32_to_cpu(1), LDST_IMM |
- LDST_CLASS_1_CCB |
- LDST_SRCDST_BYTE_CONTEXT |
- ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
- LDST_OFFSET_SHIFT));
+ append_load_imm_be32(desc, 1, LDST_IMM | LDST_CLASS_1_CCB |
+ LDST_SRCDST_BYTE_CONTEXT |
+ ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
+ LDST_OFFSET_SHIFT));
/* Class 1 operation */
append_operation(desc, ctx->class1_alg_type |
@@ -567,11 +567,10 @@ skip_enc:
/* Load Counter into CONTEXT1 reg */
if (is_rfc3686)
- append_load_imm_u32(desc, be32_to_cpu(1), LDST_IMM |
- LDST_CLASS_1_CCB |
- LDST_SRCDST_BYTE_CONTEXT |
- ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
- LDST_OFFSET_SHIFT));
+ append_load_imm_be32(desc, 1, LDST_IMM | LDST_CLASS_1_CCB |
+ LDST_SRCDST_BYTE_CONTEXT |
+ ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
+ LDST_OFFSET_SHIFT));
/* Choose operation */
if (ctr_mode)
@@ -672,11 +671,10 @@ copy_iv:
/* Load Counter into CONTEXT1 reg */
if (is_rfc3686)
- append_load_imm_u32(desc, be32_to_cpu(1), LDST_IMM |
- LDST_CLASS_1_CCB |
- LDST_SRCDST_BYTE_CONTEXT |
- ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
- LDST_OFFSET_SHIFT));
+ append_load_imm_be32(desc, 1, LDST_IMM | LDST_CLASS_1_CCB |
+ LDST_SRCDST_BYTE_CONTEXT |
+ ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
+ LDST_OFFSET_SHIFT));
/* Class 1 operation */
append_operation(desc, ctx->class1_alg_type |
@@ -1467,7 +1465,7 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
int ret = 0;
u32 *key_jump_cmd;
u32 *desc;
- u32 *nonce;
+ u8 *nonce;
u32 geniv;
u32 ctx1_iv_off = 0;
const bool ctr_mode = ((ctx->class1_alg_type & OP_ALG_AAI_MASK) ==
@@ -1520,9 +1518,10 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/* Load nonce into CONTEXT1 reg */
if (is_rfc3686) {
- nonce = (u32 *)(key + keylen);
- append_load_imm_u32(desc, *nonce, LDST_CLASS_IND_CCB |
- LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
+ nonce = (u8 *)key + keylen;
+ append_load_as_imm(desc, nonce, CTR_RFC3686_NONCE_SIZE,
+ LDST_CLASS_IND_CCB |
+ LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
append_move(desc, MOVE_WAITCOMP |
MOVE_SRC_OUTFIFO |
MOVE_DEST_CLASS1CTX |
@@ -1538,11 +1537,10 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/* Load counter into CONTEXT1 reg */
if (is_rfc3686)
- append_load_imm_u32(desc, be32_to_cpu(1), LDST_IMM |
- LDST_CLASS_1_CCB |
- LDST_SRCDST_BYTE_CONTEXT |
- ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
- LDST_OFFSET_SHIFT));
+ append_load_imm_be32(desc, 1, LDST_IMM | LDST_CLASS_1_CCB |
+ LDST_SRCDST_BYTE_CONTEXT |
+ ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
+ LDST_OFFSET_SHIFT));
/* Load operation */
append_operation(desc, ctx->class1_alg_type |
@@ -1579,9 +1577,10 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/* Load nonce into CONTEXT1 reg */
if (is_rfc3686) {
- nonce = (u32 *)(key + keylen);
- append_load_imm_u32(desc, *nonce, LDST_CLASS_IND_CCB |
- LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
+ nonce = (u8 *)key + keylen;
+ append_load_as_imm(desc, nonce, CTR_RFC3686_NONCE_SIZE,
+ LDST_CLASS_IND_CCB |
+ LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
append_move(desc, MOVE_WAITCOMP |
MOVE_SRC_OUTFIFO |
MOVE_DEST_CLASS1CTX |
@@ -1597,11 +1596,10 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/* Load counter into CONTEXT1 reg */
if (is_rfc3686)
- append_load_imm_u32(desc, be32_to_cpu(1), LDST_IMM |
- LDST_CLASS_1_CCB |
- LDST_SRCDST_BYTE_CONTEXT |
- ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
- LDST_OFFSET_SHIFT));
+ append_load_imm_be32(desc, 1, LDST_IMM | LDST_CLASS_1_CCB |
+ LDST_SRCDST_BYTE_CONTEXT |
+ ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
+ LDST_OFFSET_SHIFT));
/* Choose operation */
if (ctr_mode)
@@ -1642,9 +1640,10 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/* Load Nonce into CONTEXT1 reg */
if (is_rfc3686) {
- nonce = (u32 *)(key + keylen);
- append_load_imm_u32(desc, *nonce, LDST_CLASS_IND_CCB |
- LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
+ nonce = (u8 *)key + keylen;
+ append_load_as_imm(desc, nonce, CTR_RFC3686_NONCE_SIZE,
+ LDST_CLASS_IND_CCB |
+ LDST_SRCDST_BYTE_OUTFIFO | LDST_IMM);
append_move(desc, MOVE_WAITCOMP |
MOVE_SRC_OUTFIFO |
MOVE_DEST_CLASS1CTX |
@@ -1674,11 +1673,10 @@ static int ablkcipher_setkey(struct crypto_ablkcipher *ablkcipher,
/* Load Counter into CONTEXT1 reg */
if (is_rfc3686)
- append_load_imm_u32(desc, (u32)1, LDST_IMM |
- LDST_CLASS_1_CCB |
- LDST_SRCDST_BYTE_CONTEXT |
- ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
- LDST_OFFSET_SHIFT));
+ append_load_imm_be32(desc, 1, LDST_IMM | LDST_CLASS_1_CCB |
+ LDST_SRCDST_BYTE_CONTEXT |
+ ((ctx1_iv_off + CTR_RFC3686_IV_SIZE) <<
+ LDST_OFFSET_SHIFT));
if (ctx1_iv_off)
append_jump(desc, JUMP_JSL | JUMP_TEST_ALL | JUMP_COND_NCP |
diff --git a/drivers/crypto/caam/desc_constr.h b/drivers/crypto/caam/desc_constr.h
index d3869b9..a8cd8a7 100644
--- a/drivers/crypto/caam/desc_constr.h
+++ b/drivers/crypto/caam/desc_constr.h
@@ -325,6 +325,23 @@ static inline void append_##cmd##_imm_##type(u32 *desc, type immediate, \
APPEND_CMD_RAW_IMM(load, LOAD, u32);
/*
+ * ee - endianness
+ * size - size of immediate type in bytes
+ */
+#define APPEND_CMD_RAW_IMM2(cmd, op, ee, size) \
+static inline void append_##cmd##_imm_##ee##size(u32 *desc, \
+ u##size immediate, \
+ u32 options) \
+{ \
+ __##ee##size data = cpu_to_##ee##size(immediate); \
+ PRINT_POS; \
+ append_cmd(desc, CMD_##op | IMMEDIATE | options | sizeof(data)); \
+ append_data(desc, &data, sizeof(data)); \
+}
+
+APPEND_CMD_RAW_IMM2(load, LOAD, be, 32);
+
+/*
* Append math command. Only the last part of destination and source need to
* be specified
*/
--
1.8.3.1
^ permalink raw reply related
* Crypto Fixes for 4.8
From: Herbert Xu @ 2016-08-31 14:19 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160823095130.GA26653@gondor.apana.org.au>
Hi Linus:
This push fixes the following issues:
- Kconfig problem that prevented mxc-rnga from being enabled.
- Bogus key sizes in qat aes-xts.
- Buggy aes-xts code in vmx.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Fabian Frederick (1):
hwrng: mxc-rnga - Fix Kconfig dependency
Giovanni Cabiddu (1):
crypto: qat - fix aes-xts key sizes
Li Zhong (1):
crypto: vmx - fix null dereference in p8_aes_xts_crypt
drivers/char/hw_random/Kconfig | 2 +-
drivers/crypto/qat/qat_common/qat_algs.c | 4 ++--
drivers/crypto/vmx/aes_xts.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: hwrng: pasemi_rng.c: Migrate to managed API
From: Darren Stevens @ 2016-08-31 14:02 UTC (permalink / raw)
To: PrasannaKumar Muralidharan
Cc: Herbert Xu, linux-kernel, LABBE Corentin, linux-crypto, mpm, olof,
linuxppc-dev
In-Reply-To: <CANc+2y64+ECEh0GwQU4qQrEtsFjjbmaRJYt1t=J1Q3nT6TG6sA@mail.gmail.com>
Hello PrasannaKumar
On 30/08/2016, PrasannaKumar Muralidharan wrote:
> Hi Darren,
>> On mine (Amigaone X1000) that is correct, we boot linux with a vmlinux
>> file, and the bootloader (CFE) passes a fixed dtb. I think it is
>> possible to dump the tree from inside CFE, if it would help I can
>> invetigate?
>
> I don't know if it is possible to get dts from dtb even if you manage
> to extract devicetree blob from your system.
I didn't explain well, There is a CFE command 'show devtree' here's the
relevant bits (I Hope)
[CFE ]CFE> show devtree
[/]
| #interrupt-cells val 0x00000002
| #address-cells val 0x00000002
| #size-cells val 0x00000002
...[snip]...
[sdc@fc000000]
| name str 'sdc'
| device_type str 'sdc'
| #address-cells val 0x00000001
| #size-cells val 0x00000001
| compatible str '1682m-sdc' 'pasemi,pwrficient-sdc'
'pasemi,sdc'
| reg cell 00000000 FC000000 00000000 00800000
...[snip]...
[rng@fc105000]
| name str 'rng'
| device_type str 'rng'
| compatible str '1682m-rng' 'pasemi,pwrficient-rng'
'pasemi,rng'
| reg cell FC105000 00001000
Regards
^ permalink raw reply
* [PATCH v4 1/2] crypto: move crypto engine to its own header
From: Corentin Labbe @ 2016-08-31 12:02 UTC (permalink / raw)
To: herbert, davem, linux-crypto, baolin.wang; +Cc: linux-kernel, Corentin Labbe
In-Reply-To: <1472644978-9003-1-git-send-email-clabbe.montjoie@gmail.com>
This patch move the whole crypto engine API to its own header
crypto/engine.h.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
crypto/crypto_engine.c | 1 +
drivers/crypto/omap-aes.c | 1 +
drivers/crypto/omap-des.c | 1 +
include/crypto/algapi.h | 70 ------------------------------------
include/crypto/engine.h | 90 +++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 93 insertions(+), 70 deletions(-)
create mode 100644 include/crypto/engine.h
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index a55c82d..795b6f9 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -14,6 +14,7 @@
#include <linux/err.h>
#include <linux/delay.h>
+#include <crypto/engine.h>
#include "internal.h"
#define CRYPTO_ENGINE_MAX_QLEN 10
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 4ab53a6..993e08e 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -36,6 +36,7 @@
#include <crypto/scatterwalk.h>
#include <crypto/aes.h>
#include <crypto/algapi.h>
+#include <crypto/engine.h>
#define DST_MAXBURST 4
#define DMA_MIN (DST_MAXBURST * sizeof(u32))
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 5691434..dc36e1c 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -39,6 +39,7 @@
#include <crypto/scatterwalk.h>
#include <crypto/des.h>
#include <crypto/algapi.h>
+#include <crypto/engine.h>
#define DST_MAXBURST 2
diff --git a/include/crypto/algapi.h b/include/crypto/algapi.h
index 8637cdf..404e955 100644
--- a/include/crypto/algapi.h
+++ b/include/crypto/algapi.h
@@ -15,7 +15,6 @@
#include <linux/crypto.h>
#include <linux/list.h>
#include <linux/kernel.h>
-#include <linux/kthread.h>
#include <linux/skbuff.h>
struct crypto_aead;
@@ -129,75 +128,6 @@ struct ablkcipher_walk {
unsigned int blocksize;
};
-#define ENGINE_NAME_LEN 30
-/*
- * struct crypto_engine - crypto hardware engine
- * @name: the engine name
- * @idling: the engine is entering idle state
- * @busy: request pump is busy
- * @running: the engine is on working
- * @cur_req_prepared: current request is prepared
- * @list: link with the global crypto engine list
- * @queue_lock: spinlock to syncronise access to request queue
- * @queue: the crypto queue of the engine
- * @rt: whether this queue is set to run as a realtime task
- * @prepare_crypt_hardware: a request will soon arrive from the queue
- * so the subsystem requests the driver to prepare the hardware
- * by issuing this call
- * @unprepare_crypt_hardware: there are currently no more requests on the
- * queue so the subsystem notifies the driver that it may relax the
- * hardware by issuing this call
- * @prepare_request: do some prepare if need before handle the current request
- * @unprepare_request: undo any work done by prepare_message()
- * @crypt_one_request: do encryption for current request
- * @kworker: thread struct for request pump
- * @kworker_task: pointer to task for request pump kworker thread
- * @pump_requests: work struct for scheduling work to the request pump
- * @priv_data: the engine private data
- * @cur_req: the current request which is on processing
- */
-struct crypto_engine {
- char name[ENGINE_NAME_LEN];
- bool idling;
- bool busy;
- bool running;
- bool cur_req_prepared;
-
- struct list_head list;
- spinlock_t queue_lock;
- struct crypto_queue queue;
-
- bool rt;
-
- int (*prepare_crypt_hardware)(struct crypto_engine *engine);
- int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
-
- int (*prepare_request)(struct crypto_engine *engine,
- struct ablkcipher_request *req);
- int (*unprepare_request)(struct crypto_engine *engine,
- struct ablkcipher_request *req);
- int (*crypt_one_request)(struct crypto_engine *engine,
- struct ablkcipher_request *req);
-
- struct kthread_worker kworker;
- struct task_struct *kworker_task;
- struct kthread_work pump_requests;
-
- void *priv_data;
- struct ablkcipher_request *cur_req;
-};
-
-int crypto_transfer_request(struct crypto_engine *engine,
- struct ablkcipher_request *req, bool need_pump);
-int crypto_transfer_request_to_engine(struct crypto_engine *engine,
- struct ablkcipher_request *req);
-void crypto_finalize_request(struct crypto_engine *engine,
- struct ablkcipher_request *req, int err);
-int crypto_engine_start(struct crypto_engine *engine);
-int crypto_engine_stop(struct crypto_engine *engine);
-struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
-int crypto_engine_exit(struct crypto_engine *engine);
-
extern const struct crypto_type crypto_ablkcipher_type;
extern const struct crypto_type crypto_blkcipher_type;
diff --git a/include/crypto/engine.h b/include/crypto/engine.h
new file mode 100644
index 0000000..40899bd
--- /dev/null
+++ b/include/crypto/engine.h
@@ -0,0 +1,90 @@
+/*
+ * Crypto engine API
+ *
+ * Copyright (c) 2016 Baolin Wang <baolin.wang@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+#ifndef _CRYPTO_ENGINE_H
+#define _CRYPTO_ENGINE_H
+
+#include <linux/crypto.h>
+#include <linux/list.h>
+#include <linux/kernel.h>
+#include <linux/kthread.h>
+#include <crypto/algapi.h>
+
+#define ENGINE_NAME_LEN 30
+/*
+ * struct crypto_engine - crypto hardware engine
+ * @name: the engine name
+ * @idling: the engine is entering idle state
+ * @busy: request pump is busy
+ * @running: the engine is on working
+ * @cur_req_prepared: current request is prepared
+ * @list: link with the global crypto engine list
+ * @queue_lock: spinlock to syncronise access to request queue
+ * @queue: the crypto queue of the engine
+ * @rt: whether this queue is set to run as a realtime task
+ * @prepare_crypt_hardware: a request will soon arrive from the queue
+ * so the subsystem requests the driver to prepare the hardware
+ * by issuing this call
+ * @unprepare_crypt_hardware: there are currently no more requests on the
+ * queue so the subsystem notifies the driver that it may relax the
+ * hardware by issuing this call
+ * @prepare_request: do some prepare if need before handle the current request
+ * @unprepare_request: undo any work done by prepare_message()
+ * @crypt_one_request: do encryption for current request
+ * @kworker: thread struct for request pump
+ * @kworker_task: pointer to task for request pump kworker thread
+ * @pump_requests: work struct for scheduling work to the request pump
+ * @priv_data: the engine private data
+ * @cur_req: the current request which is on processing
+ */
+struct crypto_engine {
+ char name[ENGINE_NAME_LEN];
+ bool idling;
+ bool busy;
+ bool running;
+ bool cur_req_prepared;
+
+ struct list_head list;
+ spinlock_t queue_lock;
+ struct crypto_queue queue;
+
+ bool rt;
+
+ int (*prepare_crypt_hardware)(struct crypto_engine *engine);
+ int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
+
+ int (*prepare_request)(struct crypto_engine *engine,
+ struct ablkcipher_request *req);
+ int (*unprepare_request)(struct crypto_engine *engine,
+ struct ablkcipher_request *req);
+ int (*crypt_one_request)(struct crypto_engine *engine,
+ struct ablkcipher_request *req);
+
+ struct kthread_worker kworker;
+ struct task_struct *kworker_task;
+ struct kthread_work pump_requests;
+
+ void *priv_data;
+ struct ablkcipher_request *cur_req;
+};
+
+int crypto_transfer_request(struct crypto_engine *engine,
+ struct ablkcipher_request *req, bool need_pump);
+int crypto_transfer_request_to_engine(struct crypto_engine *engine,
+ struct ablkcipher_request *req);
+void crypto_finalize_request(struct crypto_engine *engine,
+ struct ablkcipher_request *req, int err);
+int crypto_engine_start(struct crypto_engine *engine);
+int crypto_engine_stop(struct crypto_engine *engine);
+struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
+int crypto_engine_exit(struct crypto_engine *engine);
+
+#endif /* _CRYPTO_ENGINE_H */
--
2.7.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox