* Re: [PATCH] crypto: acomp: export all scomp interfaces
From: Arnd Bergmann @ 2016-10-28 10:36 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
In-Reply-To: <20161027210328.GA12705@SILVIXA00369791-F22-1>
On Thursday, October 27, 2016 10:03:29 PM CEST Giovanni Cabiddu wrote:
> Hi Arnd,
>
> On Thu, Oct 27, 2016 at 04:09:49PM +0200, Arnd Bergmann wrote:
> > The newly added scomp/acomp interface has a couple of functions
> > that should be exported to allow linking the two drivers
> > as loadable modules:
> >
> > ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
> > ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined!
> > ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined!
> These functions were not exported on purpose. They should not be called
> by other modules.
>
> > Alternatively, both of them could be combined into one loadable module.
> I think this is the correct approach. Here is a patch with an
> alternative fix: https://patchwork.kernel.org/patch/9396503/
Yes, your patch is exactly what I had in mind as the alternative,
looks good to me.
Arnd
^ permalink raw reply
* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-28 12:37 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: linux-kernel, wens, srinivas.kandagatla, linux-crypto,
Maxime Ripard, linux-arm-kernel
In-Reply-To: <20161025090634.3dae9ad52ae8382dde6af4c8@free.fr>
On Tue, Oct 25, 2016 at 09:06:34AM +0200, Jean-Francois Moine wrote:
> On Tue, 25 Oct 2016 07:38:55 +0200
> LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
>
> > > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > > Since SID's content is constant over reboot,
> > >
> > > That's not true, at least not across all the Allwinner SoCs, and
> > > especially not on the A10 and A20 that this driver supports.
> > >
> >
> > On my cubieboard2 (A20)
> > hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> > cubiedev ~ # reboot
> > cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> > 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> > 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> > *
> > 00000200
> >
> > So clearly for me its constant.
>
> Even after power off/power on?
Yes, even after remove of any power supply.
^ permalink raw reply
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Fields Bruce James @ 2016-10-28 13:20 UTC (permalink / raw)
To: Trond Myklebust
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <DB39073B-8C4B-48BC-8D46-7B6173966037-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
On Tue, Oct 25, 2016 at 09:47:16PM +0000, Trond Myklebust wrote:
>
> > On Oct 25, 2016, at 15:59, Fields Bruce James <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:
> >
> > On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
> >> NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
> >
> > OK. Any disadvantage to keeping this patch with just GFP_NOFS
> > allocations everywhere that might be in the write path?
>
> It’s what we have to do everywhere else in the RPC client, so I can’t see why it should be a problem.
OK, the below is what I intend to merge if nobody spots another problem.
--b.
commit 2876a34466ce
Author: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Tue Oct 18 16:30:09 2016 -0400
sunrpc: don't pass on-stack memory to sg_set_buf
As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
among other callers, passes it memory on the stack.
We only need a scatterlist to pass this to the crypto code, and it seems
like overkill to require kmalloc'd memory just to encrypt a few bytes,
but for now this seems the best fix.
Many of these callers are in the NFS write paths, so we allocate with
GFP_NOFS. It might be possible to do without allocations here entirely,
but that would probably be a bigger project.
Cc: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index d8bd97a5a7c9..3dfd769dc5b5 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -1616,7 +1616,7 @@ gss_validate(struct rpc_task *task, __be32 *p)
{
struct rpc_cred *cred = task->tk_rqstp->rq_cred;
struct gss_cl_ctx *ctx = gss_cred_get_ctx(cred);
- __be32 seq;
+ __be32 *seq = NULL;
struct kvec iov;
struct xdr_buf verf_buf;
struct xdr_netobj mic;
@@ -1631,9 +1631,12 @@ gss_validate(struct rpc_task *task, __be32 *p)
goto out_bad;
if (flav != RPC_AUTH_GSS)
goto out_bad;
- seq = htonl(task->tk_rqstp->rq_seqno);
- iov.iov_base = &seq;
- iov.iov_len = sizeof(seq);
+ seq = kmalloc(4, GFP_NOFS);
+ if (!seq)
+ goto out_bad;
+ *seq = htonl(task->tk_rqstp->rq_seqno);
+ iov.iov_base = seq;
+ iov.iov_len = 4;
xdr_buf_from_iov(&iov, &verf_buf);
mic.data = (u8 *)p;
mic.len = len;
@@ -1653,11 +1656,13 @@ gss_validate(struct rpc_task *task, __be32 *p)
gss_put_ctx(ctx);
dprintk("RPC: %5u %s: gss_verify_mic succeeded.\n",
task->tk_pid, __func__);
+ kfree(seq);
return p + XDR_QUADLEN(len);
out_bad:
gss_put_ctx(ctx);
dprintk("RPC: %5u %s failed ret %ld.\n", task->tk_pid, __func__,
PTR_ERR(ret));
+ kfree(seq);
return ret;
}
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 244245bcbbd2..90115ceefd49 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -166,8 +166,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
unsigned int usage, struct xdr_netobj *cksumout)
{
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
u8 rc4salt[4];
struct crypto_ahash *md5;
struct crypto_ahash *hmac_md5;
@@ -187,23 +187,22 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
+ if (!checksumdata)
+ return GSS_S_FAILURE;
+
md5 = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(md5))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
hmac_md5 = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0,
CRYPTO_ALG_ASYNC);
- if (IS_ERR(hmac_md5)) {
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (IS_ERR(hmac_md5))
+ goto out_free_md5;
req = ahash_request_alloc(md5, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(hmac_md5);
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_hmac_md5;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -232,11 +231,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
ahash_request_free(req);
req = ahash_request_alloc(hmac_md5, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(hmac_md5);
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_hmac_md5;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -258,8 +254,12 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
cksumout->len = kctx->gk5e->cksumlength;
out:
ahash_request_free(req);
- crypto_free_ahash(md5);
+out_free_hmac_md5:
crypto_free_ahash(hmac_md5);
+out_free_md5:
+ crypto_free_ahash(md5);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -276,8 +276,8 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
struct crypto_ahash *tfm;
struct ahash_request *req;
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
unsigned int checksumlen;
if (kctx->gk5e->ctype == CKSUMTYPE_HMAC_MD5_ARCFOUR)
@@ -291,15 +291,17 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
+ if (checksumdata == NULL)
+ return GSS_S_FAILURE;
+
tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
req = ahash_request_alloc(tfm, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(tfm);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_ahash;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -349,7 +351,10 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
cksumout->len = kctx->gk5e->cksumlength;
out:
ahash_request_free(req);
+out_free_ahash:
crypto_free_ahash(tfm);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -368,8 +373,8 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
struct crypto_ahash *tfm;
struct ahash_request *req;
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
unsigned int checksumlen;
if (kctx->gk5e->keyed_cksum == 0) {
@@ -383,16 +388,18 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_NOFS);
+ if (!checksumdata)
+ return GSS_S_FAILURE;
+
tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
checksumlen = crypto_ahash_digestsize(tfm);
req = ahash_request_alloc(tfm, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(tfm);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_ahash;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -433,7 +440,10 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
}
out:
ahash_request_free(req);
+out_free_ahash:
crypto_free_ahash(tfm);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -666,14 +676,17 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
u32 ret;
struct scatterlist sg[1];
SKCIPHER_REQUEST_ON_STACK(req, cipher);
- u8 data[GSS_KRB5_MAX_BLOCKSIZE * 2];
+ u8 *data;
struct page **save_pages;
u32 len = buf->len - offset;
- if (len > ARRAY_SIZE(data)) {
+ if (len > GSS_KRB5_MAX_BLOCKSIZE * 2) {
WARN_ON(0);
return -ENOMEM;
}
+ data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_NOFS);
+ if (!data)
+ return -ENOMEM;
/*
* For encryption, we want to read from the cleartext
@@ -708,6 +721,7 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
ret = write_bytes_to_xdr_buf(buf, offset, data, len);
out:
+ kfree(data);
return ret;
}
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index d67f7e1bc82d..45662d7f0943 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -718,30 +718,37 @@ gss_write_null_verf(struct svc_rqst *rqstp)
static int
gss_write_verf(struct svc_rqst *rqstp, struct gss_ctx *ctx_id, u32 seq)
{
- __be32 xdr_seq;
+ __be32 *xdr_seq;
u32 maj_stat;
struct xdr_buf verf_data;
struct xdr_netobj mic;
__be32 *p;
struct kvec iov;
+ int err = -1;
svc_putnl(rqstp->rq_res.head, RPC_AUTH_GSS);
- xdr_seq = htonl(seq);
+ xdr_seq = kmalloc(4, GFP_KERNEL);
+ if (!xdr_seq)
+ return -1;
+ *xdr_seq = htonl(seq);
- iov.iov_base = &xdr_seq;
- iov.iov_len = sizeof(xdr_seq);
+ iov.iov_base = xdr_seq;
+ iov.iov_len = 4;
xdr_buf_from_iov(&iov, &verf_data);
p = rqstp->rq_res.head->iov_base + rqstp->rq_res.head->iov_len;
mic.data = (u8 *)(p + 1);
maj_stat = gss_get_mic(ctx_id, &verf_data, &mic);
if (maj_stat != GSS_S_COMPLETE)
- return -1;
+ goto out;
*p++ = htonl(mic.len);
memset((u8 *)p + mic.len, 0, round_up_to_quad(mic.len) - mic.len);
p += XDR_QUADLEN(mic.len);
if (!xdr_ressize_check(rqstp, p))
- return -1;
- return 0;
+ goto out;
+ err = 0;
+out:
+ kfree(xdr_seq);
+ return err;
}
struct gss_domain {
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Fields Bruce James @ 2016-10-28 13:22 UTC (permalink / raw)
To: Trond Myklebust
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto@vger.kernel.org
In-Reply-To: <20161028132008.GA8154@fieldses.org>
On Fri, Oct 28, 2016 at 09:20:08AM -0400, Fields Bruce James wrote:
> On Tue, Oct 25, 2016 at 09:47:16PM +0000, Trond Myklebust wrote:
> >
> > > On Oct 25, 2016, at 15:59, Fields Bruce James <bfields@fieldses.org> wrote:
> > >
> > > On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
> > >> NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
> > >
> > > OK. Any disadvantage to keeping this patch with just GFP_NOFS
> > > allocations everywhere that might be in the write path?
> >
> > It’s what we have to do everywhere else in the RPC client, so I can’t see why it should be a problem.
>
> OK, the below is what I intend to merge if nobody spots another problem.
And we may as well fix up some more easy stuff while we're there.
And actually moving the other crypto_alloc_* calls may be pretty easy
too, I'll see if I can get to it later....
--b.
commit 7e72f3a7c4db
Author: J. Bruce Fields <bfields@redhat.com>
Date: Wed Oct 26 16:03:00 2016 -0400
sunrpc: GFP_KERNEL should be GFP_NOFS in crypto code
Writes may depend on the auth_gss crypto code, so we shouldn't be
allocating with GFP_KERNEL there.
This still leaves some crypto_alloc_* calls which end up doing
GFP_KERNEL allocations in the crypto code. Those could probably done at
crypto import time.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 90115ceefd49..fb39284ec174 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -200,7 +200,7 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
if (IS_ERR(hmac_md5))
goto out_free_md5;
- req = ahash_request_alloc(md5, GFP_KERNEL);
+ req = ahash_request_alloc(md5, GFP_NOFS);
if (!req)
goto out_free_hmac_md5;
@@ -230,7 +230,7 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
goto out;
ahash_request_free(req);
- req = ahash_request_alloc(hmac_md5, GFP_KERNEL);
+ req = ahash_request_alloc(hmac_md5, GFP_NOFS);
if (!req)
goto out_free_hmac_md5;
@@ -299,7 +299,7 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
if (IS_ERR(tfm))
goto out_free_cksum;
- req = ahash_request_alloc(tfm, GFP_KERNEL);
+ req = ahash_request_alloc(tfm, GFP_NOFS);
if (!req)
goto out_free_ahash;
@@ -397,7 +397,7 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
goto out_free_cksum;
checksumlen = crypto_ahash_digestsize(tfm);
- req = ahash_request_alloc(tfm, GFP_KERNEL);
+ req = ahash_request_alloc(tfm, GFP_NOFS);
if (!req)
goto out_free_ahash;
@@ -963,7 +963,7 @@ krb5_rc4_setup_seq_key(struct krb5_ctx *kctx, struct crypto_skcipher *cipher,
}
desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac),
- GFP_KERNEL);
+ GFP_NOFS);
if (!desc) {
dprintk("%s: failed to allocate shash descriptor for '%s'\n",
__func__, kctx->gk5e->cksum_name);
@@ -1030,7 +1030,7 @@ krb5_rc4_setup_enc_key(struct krb5_ctx *kctx, struct crypto_skcipher *cipher,
}
desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac),
- GFP_KERNEL);
+ GFP_NOFS);
if (!desc) {
dprintk("%s: failed to allocate shash descriptor for '%s'\n",
__func__, kctx->gk5e->cksum_name);
diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c
index 60595835317a..7bb2514aadd9 100644
--- a/net/sunrpc/auth_gss/gss_krb5_mech.c
+++ b/net/sunrpc/auth_gss/gss_krb5_mech.c
@@ -451,8 +451,7 @@ context_derive_keys_rc4(struct krb5_ctx *ctx)
goto out_err_free_hmac;
- desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac),
- GFP_KERNEL);
+ desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(hmac), GFP_NOFS);
if (!desc) {
dprintk("%s: failed to allocate hash descriptor for '%s'\n",
__func__, ctx->gk5e->cksum_name);
^ permalink raw reply related
* Re: [PATCH] crypto: mxs-dcp - Remove hash support
From: Gianfranco Costamagna @ 2016-10-28 15:46 UTC (permalink / raw)
To: To: Fabio Estevam, herbert@gondor.apana.org.au, marex@denx.de,
linux-crypto@vger.kernel.org, Fabio Estevam
In-Reply-To: <CACJOhtLFGOmrLZfPjb7TXPTcqPAdCXn6H7HEHG-8iQN3Z6gJnA@mail.gmail.com>
Hi,
(sending with my debian.org mail address to avoid spam filters)
I tested the patch and indeed solves my problem (the driver loads correctly now with no warnings)
Tested-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>'
Just a side note about the patch
if (sdcp->caps & MXS_DCP_CAPABILITY1_SHA1) {
ret = crypto_register_ahash(&dcp_ sha1_alg);
if (ret) {
dev_err(dev, "Failed to register %s hash!\n",
dcp_sha1_alg.halg.base.cra_ name);
goto err_unregister_aes;
}
-err_unregister_aes:
- if (sdcp->caps & MXS_DCP_CAPABILITY1_AES128)
- crypto_unregister_algs(dcp_ae s_algs, ARRAY_SIZE(dcp_aes_algs));
-
err_destroy_aes_thread:
kthread_stop(sdcp->thread[DCP_ CHAN_CRYPTO]);
seems that in case of SHA1 register failure, the unregister was done on aes algorithm.
Probably a bad copy-paste, but removing such code will obviously fix it.
thanks,
Gianfranco
^ permalink raw reply
* [PATCH] crypto: skcipher - Get rid of crypto_grab_skcipher2()
From: Eric Biggers @ 2016-10-28 16:51 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, davem, Eric Biggers
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_grab_skcipher2() and
crypto_grab_skcipher() are equivalent. So switch callers of
crypto_grab_skcipher2() to crypto_grab_skcipher() and remove it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/authenc.c | 6 +++---
crypto/authencesn.c | 6 +++---
crypto/ccm.c | 6 +++---
crypto/chacha20poly1305.c | 6 +++---
crypto/ctr.c | 6 +++---
crypto/cts.c | 6 +++---
crypto/gcm.c | 6 +++---
include/crypto/internal/skcipher.h | 6 ------
8 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index a7e1ac7..03d5edc 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -420,9 +420,9 @@ static int crypto_authenc_create(struct crypto_template *tmpl,
goto err_free_inst;
crypto_set_skcipher_spawn(&ctx->enc, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->enc, enc_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->enc, enc_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_auth;
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index 121010a..bad6ef4 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -441,9 +441,9 @@ static int crypto_authenc_esn_create(struct crypto_template *tmpl,
goto err_free_inst;
crypto_set_skcipher_spawn(&ctx->enc, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->enc, enc_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->enc, enc_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_auth;
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 006d857..67e3636 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -544,9 +544,9 @@ static int crypto_ccm_create_common(struct crypto_template *tmpl,
goto err_free_inst;
crypto_set_skcipher_spawn(&ictx->ctr, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ictx->ctr, ctr_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ictx->ctr, ctr_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_cipher;
diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index e899ef5..66291d4 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -625,9 +625,9 @@ static int chachapoly_create(struct crypto_template *tmpl, struct rtattr **tb,
goto err_free_inst;
crypto_set_skcipher_spawn(&ctx->chacha, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->chacha, chacha_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->chacha, chacha_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_poly;
diff --git a/crypto/ctr.c b/crypto/ctr.c
index ff4d21e..57114b1 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -370,9 +370,9 @@ static int crypto_rfc3686_create(struct crypto_template *tmpl,
spawn = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher2(spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(spawn, cipher_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_free_inst;
diff --git a/crypto/cts.c b/crypto/cts.c
index 5197618..8883b62 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -348,9 +348,9 @@ static int crypto_cts_create(struct crypto_template *tmpl, struct rtattr **tb)
spawn = skcipher_instance_ctx(inst);
crypto_set_skcipher_spawn(spawn, skcipher_crypto_instance(inst));
- err = crypto_grab_skcipher2(spawn, cipher_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(spawn, cipher_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_free_inst;
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 39c261d..5f11b80 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -663,9 +663,9 @@ static int crypto_gcm_create_common(struct crypto_template *tmpl,
goto err_drop_ghash;
crypto_set_skcipher_spawn(&ctx->ctr, aead_crypto_instance(inst));
- err = crypto_grab_skcipher2(&ctx->ctr, ctr_name, 0,
- crypto_requires_sync(algt->type,
- algt->mask));
+ err = crypto_grab_skcipher(&ctx->ctr, ctr_name, 0,
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (err)
goto err_drop_ghash;
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index 95d2a18..558f5c9 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -68,12 +68,6 @@ static inline void crypto_set_skcipher_spawn(
int crypto_grab_skcipher(struct crypto_skcipher_spawn *spawn, const char *name,
u32 type, u32 mask);
-static inline int crypto_grab_skcipher2(struct crypto_skcipher_spawn *spawn,
- const char *name, u32 type, u32 mask)
-{
- return crypto_grab_skcipher(spawn, name, type, mask);
-}
-
static inline void crypto_drop_skcipher(struct crypto_skcipher_spawn *spawn)
{
crypto_drop_spawn(&spawn->base);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] crypto: skcipher - Get rid of crypto_spawn_skcipher2()
From: Eric Biggers @ 2016-10-28 16:52 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, davem, Eric Biggers
Since commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level
givcipher interface"), crypto_spawn_skcipher2() and
crypto_spawn_skcipher() are equivalent. So switch callers of
crypto_spawn_skcipher2() to crypto_spawn_skcipher() and remove it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/authenc.c | 2 +-
crypto/authencesn.c | 2 +-
crypto/ccm.c | 2 +-
crypto/chacha20poly1305.c | 2 +-
crypto/ctr.c | 2 +-
crypto/cts.c | 2 +-
crypto/gcm.c | 2 +-
include/crypto/internal/skcipher.h | 6 ------
8 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/crypto/authenc.c b/crypto/authenc.c
index 03d5edc..875470b 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -324,7 +324,7 @@ static int crypto_authenc_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(auth))
return PTR_ERR(auth);
- enc = crypto_spawn_skcipher2(&ictx->enc);
+ enc = crypto_spawn_skcipher(&ictx->enc);
err = PTR_ERR(enc);
if (IS_ERR(enc))
goto err_free_ahash;
diff --git a/crypto/authencesn.c b/crypto/authencesn.c
index bad6ef4..6f8f6b8 100644
--- a/crypto/authencesn.c
+++ b/crypto/authencesn.c
@@ -342,7 +342,7 @@ static int crypto_authenc_esn_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(auth))
return PTR_ERR(auth);
- enc = crypto_spawn_skcipher2(&ictx->enc);
+ enc = crypto_spawn_skcipher(&ictx->enc);
err = PTR_ERR(enc);
if (IS_ERR(enc))
goto err_free_ahash;
diff --git a/crypto/ccm.c b/crypto/ccm.c
index 67e3636..26b924d 100644
--- a/crypto/ccm.c
+++ b/crypto/ccm.c
@@ -462,7 +462,7 @@ static int crypto_ccm_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(cipher))
return PTR_ERR(cipher);
- ctr = crypto_spawn_skcipher2(&ictx->ctr);
+ ctr = crypto_spawn_skcipher(&ictx->ctr);
err = PTR_ERR(ctr);
if (IS_ERR(ctr))
goto err_free_cipher;
diff --git a/crypto/chacha20poly1305.c b/crypto/chacha20poly1305.c
index 66291d4..db1bc31 100644
--- a/crypto/chacha20poly1305.c
+++ b/crypto/chacha20poly1305.c
@@ -532,7 +532,7 @@ static int chachapoly_init(struct crypto_aead *tfm)
if (IS_ERR(poly))
return PTR_ERR(poly);
- chacha = crypto_spawn_skcipher2(&ictx->chacha);
+ chacha = crypto_spawn_skcipher(&ictx->chacha);
if (IS_ERR(chacha)) {
crypto_free_ahash(poly);
return PTR_ERR(chacha);
diff --git a/crypto/ctr.c b/crypto/ctr.c
index 57114b1..a9a7a44 100644
--- a/crypto/ctr.c
+++ b/crypto/ctr.c
@@ -312,7 +312,7 @@ static int crypto_rfc3686_init_tfm(struct crypto_skcipher *tfm)
unsigned long align;
unsigned int reqsize;
- cipher = crypto_spawn_skcipher2(spawn);
+ cipher = crypto_spawn_skcipher(spawn);
if (IS_ERR(cipher))
return PTR_ERR(cipher);
diff --git a/crypto/cts.c b/crypto/cts.c
index 8883b62..00254d7 100644
--- a/crypto/cts.c
+++ b/crypto/cts.c
@@ -290,7 +290,7 @@ static int crypto_cts_init_tfm(struct crypto_skcipher *tfm)
unsigned bsize;
unsigned align;
- cipher = crypto_spawn_skcipher2(spawn);
+ cipher = crypto_spawn_skcipher(spawn);
if (IS_ERR(cipher))
return PTR_ERR(cipher);
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 5f11b80..b7ad808 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -575,7 +575,7 @@ static int crypto_gcm_init_tfm(struct crypto_aead *tfm)
if (IS_ERR(ghash))
return PTR_ERR(ghash);
- ctr = crypto_spawn_skcipher2(&ictx->ctr);
+ ctr = crypto_spawn_skcipher(&ictx->ctr);
err = PTR_ERR(ctr);
if (IS_ERR(ctr))
goto err_free_hash;
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index 558f5c9..7a7e815 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -91,12 +91,6 @@ static inline struct crypto_skcipher *crypto_spawn_skcipher(
return crypto_spawn_tfm2(&spawn->base);
}
-static inline struct crypto_skcipher *crypto_spawn_skcipher2(
- struct crypto_skcipher_spawn *spawn)
-{
- return crypto_spawn_skcipher(spawn);
-}
-
static inline void crypto_skcipher_set_reqsize(
struct crypto_skcipher *skcipher, unsigned int reqsize)
{
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: ahash and crc32c
From: Horia Geanta Neag @ 2016-10-28 12:46 UTC (permalink / raw)
To: Zeev Zilberman, Herbert Xu; +Cc: linux-crypto@vger.kernel.org, David S. Miller
In-Reply-To: <CD52BAD7.26798%zeev@annapurnalabs.com>
On 2/26/2013 7:11 PM, Zeev Zilberman wrote:
> Hi,
>
> I'm working on an ahash driver that supports CRC32C.
> I saw that all existing CRC32C implementations (except blackfin) are
> implementing shash interface, but ahash seems to be the correct choice
> in our case.
> On the other hand I saw that CRC32C test in testmgr.c tries to create
> shash tfm for CRC32C and assumes that the CRC context is saved in first
> 4 bytes of the shash context.
>
> When I implement CRC32C algorithm this part of the test fails.
>
> How should I treat this failure? What is the reason for the requirement
> that is tested in this scenario?
Same question here.
I've added a crc32c ahash implementation, and reverted commit:
8e3ee85e68c5d "crypto: crc32c - Test descriptor context format"
as a temporary workaround for the testmgr.c failure.
Thanks,
Horia
^ permalink raw reply
* Alignment of shash input buffers?
From: Eric Biggers @ 2016-10-28 17:28 UTC (permalink / raw)
To: linux-crypto
Hi,
I'm having trouble understanding how alignment of shash input buffers is
supposed to work. If you pass crypto_shash_update() a buffer that is not
aligned to the shash algorithm's alignmask, it will call the underlying
->update() function twice, once with a temporary aligned buffer and once with
the aligned remainder of the original input buffer. So far so good.
The problem is that some (many?) hash algorithms actually deal with fixed size
blocks, and the lengths of buffers which users might pass to
crypto_shash_update() are not necessarily multiples of the block size. This can
cause the input buffer to fall out of alignment.
Let's use cmac(aes) as an example. It will copy up to 16 bytes to a temporary
buffer, process (xor into the state and encrypt) that block if full, then
directly process 16-byte blocks from the input buffer, then save any remainder.
The middle step uses crypto_xor() directly on the input buffer, which assumes
4-byte alignment. However this alignment is not guaranteed. For example, if I
pass two aligned buffers, one of length 15 and one of length 17 to
crypto_shash_update(), crypto_xor() is called on a misaligned pointer.
ghash is another example of an algorithm that has this problem, although that
one seems even more broken since it doesn't even set an alignmask at all (?).
I am wondering, is this intentional? If it's broken, do shash algorithms need
to be fixed to assume no alignment, e.g. by using the get_unaligned_*() macros
or by memcpy()-ing each block into a temporary buffer? Is there a better
solution?
Thanks,
Eric
^ permalink raw reply
* Re: [PATCH v2] crypto: mxs-dcp - Remove hash support
From: Horia Geanta Neag @ 2016-10-28 19:55 UTC (permalink / raw)
To: Fabio Estevam, Marek Vasut
Cc: Herbert Xu, gianfranco.costamagna@abinsula.com,
linux-crypto@vger.kernel.org, Fabio Estevam, Dan Douglass
In-Reply-To: <CAOMZO5DEdQzttFqB2rQjW_TtUU+Y29pe7rgGzhyQuZu2jcBEKA@mail.gmail.com>
On 10/25/2016 12:33 AM, Fabio Estevam wrote:
> On Mon, Oct 24, 2016 at 6:39 PM, Marek Vasut <marex@denx.de> wrote:
>
>> Can't you rather fix it?
>
> I would love to have this fixed, but I don't know how.
Looking on the i.MX6 Solo Lite security manual, the fix seems to consist
in enabling context switching - i.e. setting
DCP_CTRL[ENABLE_CONTEXT_SWITCHING] - and saving/restoring (part of) the
context buffer.
However, I am not familiar with DCP crypto engine and don't have HW to test.
Horia
^ permalink raw reply
* Re: [PATCH] crypto: mxs-dcp - Remove hash support
From: Marek Vasut @ 2016-10-28 20:05 UTC (permalink / raw)
To: Gianfranco Costamagna, To: Fabio Estevam,
herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org,
Fabio Estevam
In-Reply-To: <1477960343.1079728.1477669573195@mail.yahoo.com>
On 10/28/2016 05:46 PM, Gianfranco Costamagna wrote:
> Hi,
> (sending with my debian.org mail address to avoid spam filters)
> I tested the patch and indeed solves my problem (the driver loads correctly now with no warnings)
>
> Tested-by: Gianfranco Costamagna <gianfranco.costamagna@abinsula.com>'
Well it "solves" the problem, but it cripples the driver and removes
useful functionality.
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Mat Martineau @ 2016-10-28 22:21 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert, linux-crypto
In-Reply-To: <4087872.10iu4A8UFE@tauon.atsec.com>
Stephan,
On Fri, 28 Oct 2016, Stephan Mueller wrote:
> Am Donnerstag, 27. Oktober 2016, 14:42:14 CEST schrieb Mat Martineau:
>
> Hi Mat,
>
>> Stephan and Herbert,
>>
>> On Thu, 27 Oct 2016, Stephan Mueller wrote:
>>> Hi Herbert,
>>>
>>> for this patch, I have updated the testing for libkcapi accordingly and
>>> all
>>> tests pass. I will push the libkcapi code 0.12 with that test code change
>>> out shortly. Using the current upstream version of 0.11.1 will show
>>> failures as it expects the correct recv return code. As stated below,
>>> that return code has changed which implies that some of the tests will
>>> fail.
>>>
>>> ---8<---
>>>
>>> For encryption, the AEAD ciphers require AAD || PT as input and generate
>>> AAD || CT || Tag as output and vice versa for decryption. Prior to this
>>> patch, the AF_ALG interface for AEAD ciphers requires the buffer to be
>>> present as input for encryption. Similarly, the output buffer for
>>> decryption required the presence of the tag buffer too. This implies
>>> that the kernel reads / writes data buffers from/to user space
>>> even though this operation is not required.
>>>
>>> This patch changes the AF_ALG AEAD interface to be consistent with the
>>> in-kernel AEAD cipher memory requirements.
>>>
>>> In addition, the code now handles the situation where the provided
>>> output buffer is too small by reducing the size of the processed
>>> input buffer accordingly. Due to this handling, the changes are
>>> transparent to user space with one exception: the return code of recv
>>> indicates the processed of output buffer size. That output buffer has a
>>> different size compared to before the patch which implies that the
>>> return code of recv will also be different. For example, a decryption
>>> operation uses 16 bytes AAD, 16 bytes CT and 16 bytes tag, the AF_ALG
>>> AEAD interface before showed a recv return code of 48 (bytes) whereas
>>> after this patch, the return code is 32 since the tag is not returned
>>> any more.
>>
>> I tested out these changes and found that recv() or read() do not update
>> all of the indicated bytes. In your decrypt example where there are 16
>> bytes AAD, 16 bytes CT, and 16 bytes tag, read(sk, buf, 32) returns 32.
>
> Please check the current patch (the one I sent to you as a pre-release did not
> contain the fix for the decryption part -- the patch sent to the list and what
> we discuss here contains the appropriate handling for the decryption side).
>
> With your example using 16 bytes AAD, 16 bytes CT and 16 bytes Tag, the read
> will *only* show the return code of 16 (bytes) now, because only the CT part
> is converted into PT.
>
> Yet, you are completely correct that the first 16 bytes of the AAD are skipped
> by the read call.
>
> Thus, the read call returns exactly the amount of changed bytes, but it
> deviates from the POSIX logic by seeking to the end of the AAD buffer to find
> the offset it shall place the resulting data to.
I re-built my kernel using the patch from this email thread, and I still
see the total read() length including the "skipped" AAD byte count. Here's
an strace excerpt for a decrypt operation with AAD length of 32 and
plaintext length of 32:
sendmsg(5, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="*\200\233\350Zg\306\5ck\240\t\344\177\336 h\321\205\214<P^H~l\243\353w\34\377\316", iov_len=32},
{iov_base="\205\256}\336\27\276\31\333\321&\254w\244\244\323h\221)\254}\345s\227\242>f\266\2020\212\220\322"...,
iov_len=48}], msg_iovlen=2, msg_control=[{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x3},
{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x4}, {cmsg_len=36, cmsg_level=SOL_ALG, cmsg_type=0x2}],
msg_controllen=88, msg_flags=0}, 0) = 80
read(5, "\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1\1"..., 64) = 64
The libkcapi test behaves similarly (AEAD test 11):
sendmsg(6, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\373{\303\4\243\220\236f\342\340\305\357\225'\22\335\210L\343\3472Aq6\237,]\261\255\304\214}"...,
iov_len=68}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x3},
{cmsg_len=40, cmsg_level=SOL_ALG, cmsg_type=0x2}, {cmsg_len=20, cmsg_level=SOL_ALG, cmsg_type=0x4}],
msg_controllen=88, msg_flags=0}, 0) = 68
read(6, "\373{\303\4\243\220\236f\342\340\305\357\225'\22\335\210L\343\3472Aq6\237,]\261\255\304\214}"..., 68) = 64
Even with read() returning only the number of changed bytes, what would
you think if there was one filesystem that updated the last bytes of a
buffer in a read() call instead of the first? It's important to maintain
the standard POSIX semantics and only update the bytes starting at the
beginning of the buffer.
>
>> However, the first 16 bytes of buf are *unchanged* and the second 16 bytes
>> contain the plaintext. In other words, 16 bytes were skipped over and 16
>> bytes were read.
>
> Correct. Again, with the current patch we discuss here, the read will return
> 16 as it processed 16 bytes.
>>
>> I see how this is similar to the documented use of the dst buffer in
>> aead_request_set_crypt(), but it is not consistent with POSIX read()
>> semantics.
Regards,
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Ard Biesheuvel @ 2016-10-29 10:08 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, Russell King - ARM Linux,
Herbert Xu
Cc: Steve Capper, Ard Biesheuvel
In-Reply-To: <1476787939-21889-2-git-send-email-ard.biesheuvel@linaro.org>
On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> Wire up the generic support for exposing CPU feature bits via the
> modalias in /sys/device/system/cpu. This allows udev to automatically
> load modules for things like crypto algorithms that are implemented
> using optional instructions.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> 2 files changed, 33 insertions(+)
>
Russell,
do you have any concerns regarding this patch? If not, I will drop it
into the patch system.
Herbert,
I will resend the followup patches in this series to linux-crypto@
once this prerequisite is in place
Thanks,
Ard.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index b5d529fdffab..1a0c6a486a9c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -21,6 +21,7 @@ config ARM
> select GENERIC_ALLOCATOR
> select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> + select GENERIC_CPU_AUTOPROBE
> select GENERIC_EARLY_IOREMAP
> select GENERIC_IDLE_POLL_SETUP
> select GENERIC_IRQ_PROBE
> diff --git a/arch/arm/include/asm/cpufeature.h b/arch/arm/include/asm/cpufeature.h
> new file mode 100644
> index 000000000000..19c3dddd901a
> --- /dev/null
> +++ b/arch/arm/include/asm/cpufeature.h
> @@ -0,0 +1,32 @@
> +/*
> + * Copyright (C) 2016 Linaro Ltd. <ard.biesheuvel@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __ASM_CPUFEATURE_H
> +#define __ASM_CPUFEATURE_H
> +
> +#include <asm/hwcap.h>
> +
> +/*
> + * Due to the fact that ELF_HWCAP is a 32-bit type on ARM, and given the number
> + * of optional CPU features it defines, ARM's CPU capability bits have been
> + * divided across separate elf_hwcap and elf_hwcap2 variables, each of which
> + * covers a subset of the available CPU features.
> + *
> + * Currently, only a few of those are suitable for automatic module loading
> + * (which is the primary use case of this facility) and those happen to be all
> + * covered by HWCAP2. So let's only expose those via the CPU modalias for now.
> + */
> +#define MAX_CPU_FEATURES (8 * sizeof(elf_hwcap2))
> +#define cpu_feature(x) ilog2(HWCAP2_ ## x)
> +
> +static inline bool cpu_have_feature(unsigned int num)
> +{
> + return elf_hwcap2 & (1UL << num);
> +}
> +
> +#endif
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH v2] crypto: mxs-dcp - Remove hash support
From: Fabio Estevam @ 2016-10-29 15:25 UTC (permalink / raw)
To: Horia Geanta Neag
Cc: Marek Vasut, Herbert Xu, gianfranco.costamagna@abinsula.com,
linux-crypto@vger.kernel.org, Fabio Estevam, Dan Douglass
In-Reply-To: <AMSPR04MB083958F93F3E945D0B57D6EE98AD0@AMSPR04MB0839.eurprd04.prod.outlook.com>
Hi Horia,
On Fri, Oct 28, 2016 at 5:55 PM, Horia Geanta Neag <horia.geanta@nxp.com> wrote:
> Looking on the i.MX6 Solo Lite security manual, the fix seems to consist
> in enabling context switching - i.e. setting
> DCP_CTRL[ENABLE_CONTEXT_SWITCHING] - and saving/restoring (part of) the
> context buffer.
>
> However, I am not familiar with DCP crypto engine and don't have HW to test.
I do have access to hardware to test. Could you please propose some
patches I can try?
My previous attempt to fix this issue was this one:
http://www.spinics.net/lists/linux-crypto/msg18039.html
Thanks,
Fabio Estevam
^ permalink raw reply
* 9387721 linux-crypto
From: cdevries @ 2016-10-30 13:49 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: grlinux-crypto.zip --]
[-- Type: application/zip, Size: 12782 bytes --]
^ permalink raw reply
* Re: [RESEND][PATCH] crypto: caam: add support for iMX6UL
From: Russell King - ARM Linux @ 2016-10-31 8:20 UTC (permalink / raw)
To: Marcus Folkesson
Cc: Herbert Xu, David S . Miller, Rob Herring, Mark Rutland,
Horia Geanta, Arnd Bergmann, Alex Porosanu, Srinivas Kandagatla,
Baoyou Xie, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476703680-22676-1-git-send-email-marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Horia Geantă <horia.geanta-3arQi8VN3Tc@public.gmane.org>
> ---
> .../devicetree/bindings/crypto/fsl-sec4.txt | 20 +++++++++++++
> drivers/crypto/caam/ctrl.c | 35 ++++++++++++----------
> 2 files changed, 40 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> index adeca34..10a425f 100644
> --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> @@ -123,6 +123,9 @@ PROPERTIES
>
>
> EXAMPLE
> +
> +iMX6QDL/SX requires four clocks
> +
> crypto@300000 {
> compatible = "fsl,sec-v4.0";
> fsl,sec-era = <2>;
> @@ -139,6 +142,23 @@ EXAMPLE
> clock-names = "mem", "aclk", "ipg", "emi_slow";
> };
>
> +
> +iMX6UL does only require three clocks
> +
> + crypto: caam@2140000 {
> + compatible = "fsl,sec-v4.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x2140000 0x3c000>;
> + ranges = <0 0x2140000 0x3c000>;
> + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&clks IMX6UL_CLK_CAAM_MEM>,
> + <&clks IMX6UL_CLK_CAAM_ACLK>,
> + <&clks IMX6UL_CLK_CAAM_IPG>;
> + clock-names = "mem", "aclk", "ipg";
> + };
> +
> =====================================================================
> Job Ring (JR) Node
>
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index 0ec112e..5abaf37 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -329,8 +329,8 @@ static int caam_remove(struct platform_device *pdev)
> clk_disable_unprepare(ctrlpriv->caam_ipg);
> clk_disable_unprepare(ctrlpriv->caam_mem);
> clk_disable_unprepare(ctrlpriv->caam_aclk);
> - clk_disable_unprepare(ctrlpriv->caam_emi_slow);
> -
> + if (!of_machine_is_compatible("fsl,imx6ul"))
> + clk_disable_unprepare(ctrlpriv->caam_emi_slow);
There is no need to re-lookup the platform here. Can't you check the
validity of ctrlpriv->caam_emi_slow ?
> return 0;
> }
>
> @@ -481,14 +481,16 @@ static int caam_probe(struct platform_device *pdev)
> }
> ctrlpriv->caam_aclk = clk;
>
> - clk = caam_drv_identify_clk(&pdev->dev, "emi_slow");
> - if (IS_ERR(clk)) {
> - ret = PTR_ERR(clk);
> - dev_err(&pdev->dev,
> - "can't identify CAAM emi_slow clk: %d\n", ret);
> - return ret;
> + if (!of_machine_is_compatible("fsl,imx6ul")) {
> + clk = caam_drv_identify_clk(&pdev->dev, "emi_slow");
> + if (IS_ERR(clk)) {
> + ret = PTR_ERR(clk);
> + dev_err(&pdev->dev,
> + "can't identify CAAM emi_slow clk: %d\n", ret);
> + return ret;
> + }
> + ctrlpriv->caam_emi_slow = clk;
> }
> - ctrlpriv->caam_emi_slow = clk;
>
> ret = clk_prepare_enable(ctrlpriv->caam_ipg);
> if (ret < 0) {
> @@ -509,11 +511,13 @@ static int caam_probe(struct platform_device *pdev)
> goto disable_caam_mem;
> }
>
> - ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "can't enable CAAM emi slow clock: %d\n",
> - ret);
> - goto disable_caam_aclk;
> + if (!of_machine_is_compatible("fsl,imx6ul")) {
Same here.
> + ret = clk_prepare_enable(ctrlpriv->caam_emi_slow);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "can't enable CAAM emi slow clock: %d\n",
> + ret);
> + goto disable_caam_aclk;
> + }
> }
>
> /* Get configuration properties from device tree */
> @@ -829,7 +833,8 @@ caam_remove:
> iounmap_ctrl:
> iounmap(ctrl);
> disable_caam_emi_slow:
> - clk_disable_unprepare(ctrlpriv->caam_emi_slow);
> + if (!of_machine_is_compatible("fsl,imx6ul"))
> + clk_disable_unprepare(ctrlpriv->caam_emi_slow);
and here.
> disable_caam_aclk:
> clk_disable_unprepare(ctrlpriv->caam_aclk);
> disable_caam_mem:
> --
> 2.8.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 双11预售专场已经开启！低至五折，双十一前囤货高峰！
From: 一次性无菌注射针 @ 2016-10-31 9:01 UTC (permalink / raw)
To: linux-crypto
双11海量好货提前曝光
提前查看双11好货，抢先收藏，双11当天立即下单，避免排队付款，不止是五折！
电脑用户入口：http://s.click.taobao.com/0DPUWPx
手机用户入口：http://s.click.taobao.com/XQlUWPx
^ permalink raw reply
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Stephan Mueller @ 2016-10-31 10:11 UTC (permalink / raw)
To: Mat Martineau; +Cc: herbert, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1610281501490.9348@mjmartin-mac01.wa.intel.com>
Am Freitag, 28. Oktober 2016, 15:21:19 CET schrieb Mat Martineau:
Hi Mat,
> >
> > Please check the current patch (the one I sent to you as a pre-release did
> > not contain the fix for the decryption part -- the patch sent to the list
> > and what we discuss here contains the appropriate handling for the
> > decryption side).
> >
> > With your example using 16 bytes AAD, 16 bytes CT and 16 bytes Tag, the
> > read will *only* show the return code of 16 (bytes) now, because only the
> > CT part is converted into PT.
> >
> > Yet, you are completely correct that the first 16 bytes of the AAD are
> > skipped by the read call.
> >
> > Thus, the read call returns exactly the amount of changed bytes, but it
> > deviates from the POSIX logic by seeking to the end of the AAD buffer to
> > find the offset it shall place the resulting data to.
>
> I re-built my kernel using the patch from this email thread, and I still
> see the total read() length including the "skipped" AAD byte count. Here's
> an strace excerpt for a decrypt operation with AAD length of 32 and
> plaintext length of 32:
That is absolutely correct as the patch' intention is to avoid the
superflowous Tag memory consideration for input data during encryption and for
output data for decryption. This prevents the kernel from reading/writing
memory that it does not need to touch.
The patch is not intended for coverting the AAD you reported. Though, I am not
yet sure about whether we need to cover that aspect. My interpretation is that
the kernel is responsible for the entire memory of AAD || PT/CT and
potentially the tag. If the kernel sees that it does not need to change the
AAD, it will not do that and simply change the parts of the buffer it needs
to. Then, the kernel reports the changed bytes.
Note, if we change the kernel to operate as you suggest, there is more memory
re-calculation operation in the kernel as well as in user space. To me, that
is an invtation to errors. Besides, I see that only as an interpretation of
how POSIX is to be applied.
However, I can make another proposal: we change the read/recv handler such
that it returns the actually processed memory, regardless whether it really
touched it. I.e. read will return the following bytes in its return code:
- encryption: AAD + CT + Tag
- decryption: AAD + PT
Even though read would report that amount of memory, we all know that the AAD
part will not be actually written. Yet, the kernel returns the amount of bytes
it processed.
Regardless, all of this discussion revolves around a topic that is separate to
this patch. I.e. this patch was not intended to handle the AAD. This patch is
only provided to handle the tag.
...
Ciao
Stephan
^ permalink raw reply
* 51407843978 linux-crypto
From: douille.l @ 2016-10-31 12:05 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: aelinux-crypto.zip --]
[-- Type: application/zip, Size: 6140 bytes --]
^ permalink raw reply
* [PATCH] crypto: cryptd - Remove unused but set variable 'tfm'
From: Tobias Klauser @ 2016-10-31 14:42 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: linux-crypto
Remove the unused but set variable tfm in cryptd_enqueue_request to fix
the following warning when building with 'W=1':
crypto/cryptd.c:125:21: warning: variable 'tfm' set but not used [-Wunused-but-set-variable]
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
crypto/cryptd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/crypto/cryptd.c b/crypto/cryptd.c
index 0c654e59f215..3fd2a20a8145 100644
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -122,7 +122,6 @@ static int cryptd_enqueue_request(struct cryptd_queue *queue,
{
int cpu, err;
struct cryptd_cpu_queue *cpu_queue;
- struct crypto_tfm *tfm;
atomic_t *refcnt;
bool may_backlog;
@@ -141,7 +140,6 @@ static int cryptd_enqueue_request(struct cryptd_queue *queue,
if (!atomic_read(refcnt))
goto out_put_cpu;
- tfm = request->tfm;
atomic_inc(refcnt);
out_put_cpu:
--
2.9.0
^ permalink raw reply related
* Re: [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Russell King - ARM Linux @ 2016-10-31 16:13 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, Herbert Xu, Steve Capper
In-Reply-To: <CAKv+Gu_y7e=sJT+7FNj846NczgpNOdVx53SDC7dupmN-3ztNwA@mail.gmail.com>
On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Wire up the generic support for exposing CPU feature bits via the
> > modalias in /sys/device/system/cpu. This allows udev to automatically
> > load modules for things like crypto algorithms that are implemented
> > using optional instructions.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm/Kconfig | 1 +
> > arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> > 2 files changed, 33 insertions(+)
> >
>
> Russell,
>
> do you have any concerns regarding this patch? If not, I will drop it
> into the patch system.
It's still something I need to look at... I've been offline last week,
and sort-of offline the previous week, so I'm catching up.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] crypto: fix AEAD tag memory handling
From: Mat Martineau @ 2016-10-31 23:18 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert, linux-crypto
In-Reply-To: <2822295.gL4fqFHz8h@positron.chronox.de>
Hi Stephan -
On Mon, 31 Oct 2016, Stephan Mueller wrote:
> Am Freitag, 28. Oktober 2016, 15:21:19 CET schrieb Mat Martineau:
>
> Hi Mat,
>>>
>>> Please check the current patch (the one I sent to you as a pre-release did
>>> not contain the fix for the decryption part -- the patch sent to the list
>>> and what we discuss here contains the appropriate handling for the
>>> decryption side).
>>>
>>> With your example using 16 bytes AAD, 16 bytes CT and 16 bytes Tag, the
>>> read will *only* show the return code of 16 (bytes) now, because only the
>>> CT part is converted into PT.
>>>
>>> Yet, you are completely correct that the first 16 bytes of the AAD are
>>> skipped by the read call.
>>>
>>> Thus, the read call returns exactly the amount of changed bytes, but it
>>> deviates from the POSIX logic by seeking to the end of the AAD buffer to
>>> find the offset it shall place the resulting data to.
>>
>> I re-built my kernel using the patch from this email thread, and I still
>> see the total read() length including the "skipped" AAD byte count. Here's
>> an strace excerpt for a decrypt operation with AAD length of 32 and
>> plaintext length of 32:
>
> That is absolutely correct as the patch' intention is to avoid the
> superflowous Tag memory consideration for input data during encryption and for
> output data for decryption. This prevents the kernel from reading/writing
> memory that it does not need to touch.
>
> The patch is not intended for coverting the AAD you reported. Though, I am not
> yet sure about whether we need to cover that aspect. My interpretation is that
> the kernel is responsible for the entire memory of AAD || PT/CT and
> potentially the tag. If the kernel sees that it does not need to change the
> AAD, it will not do that and simply change the parts of the buffer it needs
> to. Then, the kernel reports the changed bytes.
>
> Note, if we change the kernel to operate as you suggest, there is more memory
> re-calculation operation in the kernel as well as in user space. To me, that
> is an invtation to errors.
To be clear: my preference is to have read() copy only PT or CT||Tag bytes
in to the provided buffer. sendmsg() is for input, read() is for output.
AAD is input and was passed to the kernel in the sendmsg() call.
My second choice is to write the AAD bytes to the read() buffer in order
to work better with existing userspace code.
I don't see that there is extra userspace manipulation of memory if the
read() buffer does not include space for AAD. The userspace program just
passes a pointer to the location for PT or CT||Tag as the buffer pointer
for read() - the bytes for AAD may already be in the memory preceding that
pointer.
> Besides, I see that only as an interpretation of
> how POSIX is to be applied.
We seem to be at an impasse here: I contend that this aspect of POSIX
read() is not open to interpretation. When read() returns a positive
number N, that means the *first* N bytes of the buffer were updated.
Making the programmer second guess which N bytes of the buffer were
changed depending on which filesystem / socket type / etc is in use for
that file descriptor is a recipe for serious bugs and seriously breaks
the "everything is a file" abstraction.
> However, I can make another proposal: we change the read/recv handler such
> that it returns the actually processed memory, regardless whether it really
> touched it. I.e. read will return the following bytes in its return code:
>
> - encryption: AAD + CT + Tag
>
> - decryption: AAD + PT
>
> Even though read would report that amount of memory, we all know that the AAD
> part will not be actually written. Yet, the kernel returns the amount of bytes
> it processed.
This is what I was attempting to document in my previous reply: strace is
showing that this is already the behavior implemented by the current
patch.
> Regardless, all of this discussion revolves around a topic that is separate to
> this patch. I.e. this patch was not intended to handle the AAD. This patch is
> only provided to handle the tag.
My main concern is getting the semantics correct and consistent in a
single patch series. It would be a big problem to explain that AF_ALG AEAD
read and write works one way in 4.x, another way in 4.y, and some
different way in 4.z.
--
Mat Martineau
Intel OTC
^ permalink raw reply
* Re: [PATCH 0/3] crypto: testmgr - Add missing tests for internal sha*-mb implementations
From: Herbert Xu @ 2016-11-01 0:32 UTC (permalink / raw)
To: Marcelo Cerri
Cc: linux-crypto, David S. Miller, linux-kernel, Stephan Mueller
In-Reply-To: <1477501485-18371-1-git-send-email-marcelo.cerri@canonical.com>
On Wed, Oct 26, 2016 at 03:04:42PM -0200, Marcelo Cerri wrote:
> This series adds null tests for all sha*-mb internal algorithms so they can
> be used in FIPS mode without further problems.
>
> Since they are 3 separated modules I decided to use a separated commit for
> each one.
>
> Marcelo Cerri (3):
> crypto: testmgr - Add missing tests for internal sha1-mb
> implementation
> crypto: testmgr - Add missing tests for internal sha256-mb
> implementation
> crypto: testmgr - Add missing tests for internal sha512-mb
> implementation
>
> crypto/testmgr.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
I have a patch pending that skips testing of all internal algorithms.
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] hwrng: core - zeroize buffers with random data
From: Herbert Xu @ 2016-11-01 0:42 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto, Andy Lutomirski
In-Reply-To: <5934786.pstHyKoYpf@positron.chronox.de>
On Sat, Oct 22, 2016 at 03:57:05PM +0200, Stephan Mueller wrote:
>
> The HWRNG core allocates two buffers during initialization which are
> used to obtain random data. After that data is processed, it is now
> zeroized as it is possible that the HWRNG core will not be asked to
> produce more random data for a long time. This prevents leaving such
> sensitive data in memory.
>
> 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 -next] crypto: drop pointless static qualifier in atmel_aes_probe()
From: Herbert Xu @ 2016-11-01 0:43 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, linux-crypto
In-Reply-To: <1477320682-6881-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 24, 2016 at 02:51:22PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> There is no need to have the 'struct atmel_aes_dev *aes_dd' variable
> static since new value always be assigned before use it.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.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
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