* Re: [PATCH] crypto: cmac - fix alignment of 'consts'
From: Eric Biggers @ 2016-10-10 18:07 UTC (permalink / raw)
To: Joe Perches; +Cc: herbert, davem, linux-crypto, linux-kernel
In-Reply-To: <1476121874.2856.30.camel@perches.com>
On Mon, Oct 10, 2016 at 10:51:14AM -0700, Joe Perches wrote:
>
> Hey Eric.
>
> I don't see any PTR_ALIGN uses in crypto/ or drivers/crypto/ that
> use a bitwise or, just mask + 1, but I believe the effect is the
> same. Anyway, your choice, but I think using min is clearer.
>
> cheers, Joe
Usually the bitwise OR is used when setting cra_alignmask in the 'struct
crypto_alg'. Indeed, the problem could be solved by setting
inst->alg.base.cra_alignmask = alg->cra_alignmask | (__alignof__(__be64) - 1);
I decided against that because it would always force 8-byte alignment for CMAC
input buffers and keys, when in fact they don't need that level of alignment
unless the underlying block cipher requires it.
Eric
^ permalink raw reply
* Re: [PATCH] crypto: cmac - fix alignment of 'consts'
From: Joe Perches @ 2016-10-10 17:51 UTC (permalink / raw)
To: Eric Biggers; +Cc: herbert, davem, linux-crypto, linux-kernel
In-Reply-To: <20161010173756.GA115716@google.com>
On Mon, 2016-10-10 at 10:37 -0700, Eric Biggers wrote:
> On Mon, Oct 10, 2016 at 10:29:55AM -0700, Joe Perches wrote:
> > On Mon, 2016-10-10 at 10:15 -0700, Eric Biggers wrote:
> > > The per-transform 'consts' array is accessed as __be64 in
> > > crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
> > > __alignof__(long). Fix this by aligning it to __alignof__(__be64).
> > []
> > > diff --git a/crypto/cmac.c b/crypto/cmac.c
> > []
> > > @@ -57,7 +57,8 @@ static int crypto_cmac_digest_setkey(struct crypto_shash *parent,
> > > unsigned long alignmask = crypto_shash_alignmask(parent);
> > > struct cmac_tfm_ctx *ctx = crypto_shash_ctx(parent);
> > > unsigned int bs = crypto_shash_blocksize(parent);
> > > - __be64 *consts = PTR_ALIGN((void *)ctx->ctx, alignmask + 1);
> > > + __be64 *consts = PTR_ALIGN((void *)ctx->ctx,
> > > + (alignmask | (__alignof__(__be64) - 1)) + 1);
> >
> >
> > Using a bitwise or looks very odd there. Perhaps:
> >
> > min(alignmask + 1, __alignof__(__be64))
> >
>
>
> Alignment has to be a power of 2. From the code I've read, crypto drivers work
> with alignment a lot and use bitwise OR to mean "the more restrictive of these
> alignmasks". So I believe the way it's written is the preferred style.
>
> Eric
Hey Eric.
I don't see any PTR_ALIGN uses in crypto/ or drivers/crypto/ that
use a bitwise or, just mask + 1, but I believe the effect is the
same. Anyway, your choice, but I think using min is clearer.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] crypto: cmac - fix alignment of 'consts'
From: Eric Biggers @ 2016-10-10 17:37 UTC (permalink / raw)
To: Joe Perches; +Cc: herbert, davem, linux-crypto, linux-kernel
In-Reply-To: <1476120595.2856.28.camel@perches.com>
On Mon, Oct 10, 2016 at 10:29:55AM -0700, Joe Perches wrote:
> On Mon, 2016-10-10 at 10:15 -0700, Eric Biggers wrote:
> > The per-transform 'consts' array is accessed as __be64 in
> > crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
> > __alignof__(long). Fix this by aligning it to __alignof__(__be64).
> []
> > diff --git a/crypto/cmac.c b/crypto/cmac.c
> []
> > @@ -57,7 +57,8 @@ static int crypto_cmac_digest_setkey(struct crypto_shash *parent,
> > unsigned long alignmask = crypto_shash_alignmask(parent);
> > struct cmac_tfm_ctx *ctx = crypto_shash_ctx(parent);
> > unsigned int bs = crypto_shash_blocksize(parent);
> > - __be64 *consts = PTR_ALIGN((void *)ctx->ctx, alignmask + 1);
> > + __be64 *consts = PTR_ALIGN((void *)ctx->ctx,
> > + (alignmask | (__alignof__(__be64) - 1)) + 1);
>
> Using a bitwise or looks very odd there. Perhaps:
>
> min(alignmask + 1, __alignof__(__be64))
>
Alignment has to be a power of 2. From the code I've read, crypto drivers work
with alignment a lot and use bitwise OR to mean "the more restrictive of these
alignmasks". So I believe the way it's written is the preferred style.
Eric
^ permalink raw reply
* Re: [PATCH] crypto: cmac - fix alignment of 'consts'
From: Joe Perches @ 2016-10-10 17:29 UTC (permalink / raw)
To: Eric Biggers, herbert, davem; +Cc: linux-crypto, linux-kernel
In-Reply-To: <1476119715-71397-2-git-send-email-ebiggers@google.com>
On Mon, 2016-10-10 at 10:15 -0700, Eric Biggers wrote:
> The per-transform 'consts' array is accessed as __be64 in
> crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
> __alignof__(long). Fix this by aligning it to __alignof__(__be64).
[]
> diff --git a/crypto/cmac.c b/crypto/cmac.c
[]
> @@ -57,7 +57,8 @@ static int crypto_cmac_digest_setkey(struct crypto_shash *parent,
> unsigned long alignmask = crypto_shash_alignmask(parent);
> struct cmac_tfm_ctx *ctx = crypto_shash_ctx(parent);
> unsigned int bs = crypto_shash_blocksize(parent);
> - __be64 *consts = PTR_ALIGN((void *)ctx->ctx, alignmask + 1);
> + __be64 *consts = PTR_ALIGN((void *)ctx->ctx,
> + (alignmask | (__alignof__(__be64) - 1)) + 1);
Using a bitwise or looks very odd there. Perhaps:
min(alignmask + 1, __alignof__(__be64))
^ permalink raw reply
* [PATCH] crypto: cmac - fix alignment of 'consts'
From: Eric Biggers @ 2016-10-10 17:15 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, linux-kernel, Eric Biggers
The per-transform 'consts' array is accessed as __be64 in
crypto_cmac_digest_setkey() but was only guaranteed to be aligned to
__alignof__(long). Fix this by aligning it to __alignof__(__be64).
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/cmac.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/crypto/cmac.c b/crypto/cmac.c
index b6c4059..04080dc 100644
--- a/crypto/cmac.c
+++ b/crypto/cmac.c
@@ -57,7 +57,8 @@ static int crypto_cmac_digest_setkey(struct crypto_shash *parent,
unsigned long alignmask = crypto_shash_alignmask(parent);
struct cmac_tfm_ctx *ctx = crypto_shash_ctx(parent);
unsigned int bs = crypto_shash_blocksize(parent);
- __be64 *consts = PTR_ALIGN((void *)ctx->ctx, alignmask + 1);
+ __be64 *consts = PTR_ALIGN((void *)ctx->ctx,
+ (alignmask | (__alignof__(__be64) - 1)) + 1);
u64 _const[2];
int i, err = 0;
u8 msb_mask, gfmask;
@@ -173,7 +174,8 @@ static int crypto_cmac_digest_final(struct shash_desc *pdesc, u8 *out)
struct cmac_desc_ctx *ctx = shash_desc_ctx(pdesc);
struct crypto_cipher *tfm = tctx->child;
int bs = crypto_shash_blocksize(parent);
- u8 *consts = PTR_ALIGN((void *)tctx->ctx, alignmask + 1);
+ u8 *consts = PTR_ALIGN((void *)tctx->ctx,
+ (alignmask | (__alignof__(__be64) - 1)) + 1);
u8 *odds = PTR_ALIGN((void *)ctx->ctx, alignmask + 1);
u8 *prev = odds + bs;
unsigned int offset = 0;
@@ -258,7 +260,8 @@ static int cmac_create(struct crypto_template *tmpl, struct rtattr **tb)
if (err)
goto out_free_inst;
- alignmask = alg->cra_alignmask | (sizeof(long) - 1);
+ /* We access the data as u32s when xoring. */
+ alignmask = alg->cra_alignmask | (__alignof__(u32) - 1);
inst->alg.base.cra_alignmask = alignmask;
inst->alg.base.cra_priority = alg->cra_priority;
inst->alg.base.cra_blocksize = alg->cra_blocksize;
@@ -270,7 +273,9 @@ static int cmac_create(struct crypto_template *tmpl, struct rtattr **tb)
+ alg->cra_blocksize * 2;
inst->alg.base.cra_ctxsize =
- ALIGN(sizeof(struct cmac_tfm_ctx), alignmask + 1)
+ ALIGN(sizeof(struct cmac_tfm_ctx), crypto_tfm_ctx_alignment())
+ + ((alignmask | (__alignof__(__be64) - 1)) &
+ ~(crypto_tfm_ctx_alignment() - 1))
+ alg->cra_blocksize * 2;
inst->alg.base.cra_init = cmac_init_tfm;
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] crypto: cmac - return -EINVAL if block size is unsupported
From: Eric Biggers @ 2016-10-10 17:15 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, linux-kernel, Eric Biggers
cmac_create() previously returned 0 if a cipher with a block size other
than 8 or 16 bytes was specified. It should return -EINVAL instead.
Granted, this doesn't actually change any behavior because cryptomgr
currently ignores any return value other than -EAGAIN from template
->create() functions.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/cmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/cmac.c b/crypto/cmac.c
index 7a8bfbd..b6c4059 100644
--- a/crypto/cmac.c
+++ b/crypto/cmac.c
@@ -243,6 +243,7 @@ static int cmac_create(struct crypto_template *tmpl, struct rtattr **tb)
case 8:
break;
default:
+ err = -EINVAL;
goto out_put_alg;
}
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] crypto: ccp - change bitfield type to unsigned ints
From: Gary R Hook @ 2016-10-10 15:34 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, herbert, davem
Bit fields are not sensitive to endianness, so use
a transparent standard data type
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev.h | 42 +++++++++++++++++++++---------------------
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index da5f4a6..0d996fe 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -541,23 +541,23 @@ static inline u32 ccp_addr_hi(struct ccp_dma_info *info)
* word 7: upper 16 bits of key pointer; key memory type
*/
struct dword0 {
- __le32 soc:1;
- __le32 ioc:1;
- __le32 rsvd1:1;
- __le32 init:1;
- __le32 eom:1; /* AES/SHA only */
- __le32 function:15;
- __le32 engine:4;
- __le32 prot:1;
- __le32 rsvd2:7;
+ unsigned int soc:1;
+ unsigned int ioc:1;
+ unsigned int rsvd1:1;
+ unsigned int init:1;
+ unsigned int eom:1; /* AES/SHA only */
+ unsigned int function:15;
+ unsigned int engine:4;
+ unsigned int prot:1;
+ unsigned int rsvd2:7;
};
struct dword3 {
- __le32 src_hi:16;
- __le32 src_mem:2;
- __le32 lsb_cxt_id:8;
- __le32 rsvd1:5;
- __le32 fixed:1;
+ unsigned int src_hi:16;
+ unsigned int src_mem:2;
+ unsigned int lsb_cxt_id:8;
+ unsigned int rsvd1:5;
+ unsigned int fixed:1;
};
union dword4 {
@@ -567,18 +567,18 @@ union dword4 {
union dword5 {
struct {
- __le32 dst_hi:16;
- __le32 dst_mem:2;
- __le32 rsvd1:13;
- __le32 fixed:1;
+ unsigned int dst_hi:16;
+ unsigned int dst_mem:2;
+ unsigned int rsvd1:13;
+ unsigned int fixed:1;
} fields;
__le32 sha_len_hi;
};
struct dword7 {
- __le32 key_hi:16;
- __le32 key_mem:2;
- __le32 rsvd1:14;
+ unsigned int key_hi:16;
+ unsigned int key_mem:2;
+ unsigned int rsvd1:14;
};
struct ccp5_desc {
^ permalink raw reply related
* Re: [PATCH 0/6] crypto: arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-10 11:26 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Herbert Xu
Cc: Catalin Marinas, Will Deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
On 9 October 2016 at 18:42, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
> currently work, or have ever worked correctly when built for big endian. So this
> series fixes all of them.
>
> Each of these patches carries a fixes tag, and could be backported to stable.
> However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
> fix is compatible with, not the patch that introduced the algorithm. This is due
> to the fact that the key schedules are incompatible between generic AES and the
> arm64 Crypto Extensions implementation (but only when building for big endian)
> This is not a problem in practice, but it does mean that the AES-CCM and AES in
> EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
> one that is compatible with the generic AES key schedule generation code (which
> it currently no longer uses)
>
> In any case, please apply with cc to stable.
>
Herbert,
I have an additional fix to add to this series, and a couple for
32-bit ARM as well. They escaped my attention due to this code (in
algboss.c:250)
/* This piece of crap needs to disappear into per-type test hooks. */
if (!((type ^ CRYPTO_ALG_TYPE_BLKCIPHER) &
CRYPTO_ALG_TYPE_BLKCIPHER_MASK) && !(type & CRYPTO_ALG_GENIV) &&
((alg->cra_flags & CRYPTO_ALG_TYPE_MASK) ==
CRYPTO_ALG_TYPE_BLKCIPHER ? alg->cra_blkcipher.ivsize :
alg->cra_ablkcipher.ivsize))
type |= CRYPTO_ALG_TESTED;
This causes cbc(aes), ctr(aes) and xts(aes) to remain untested, unless
I add CRYPTO_ALG_GENIV to their cra_flags. Is this expected behavior?
What would be your recommended way to ensure these algos are covered
by the boottime tests?
Thanks,
Ard.
^ permalink raw reply
* Re: chacha counters in random.c
From: Sami Farin @ 2016-10-10 5:35 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Theodore Ts'o, linux-crypto
In-Reply-To: <9777512.vL8nZQ0s3r@positron.chronox.de>
On Mon, Oct 10, 2016 at 05:34:28 +0200, Stephan Mueller wrote:
> Am Sonntag, 9. Oktober 2016, 20:16:27 CEST schrieb Sami Farin:
>
> Hi Sami,
>
> > commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
> >
> > + chacha20_block(&crng->state[0], out);
> > + if (crng->state[12] == 0)
> > + crng->state[13]++;
> >
> > Did you mean
> > + if (++crng->state[12] == 0)
>
> Please see chacha20_block at the end:
>
> state[12]++;
>
> I would guess that this is the increment you are looking for.
Oh yeah, there it is.
--
Do what you love because life is too short for anything else.
^ permalink raw reply
* Crypto Update for 4.9
From: Herbert Xu @ 2016-10-10 3:34 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20160725105300.GA5894@gondor.apana.org.au>
Hi Linus:
Here is the crypto update for 4.9:
API:
* The crypto engine code now supports hashes.
Algorithms:
* Allow keys >= 2048 bits in FIPS mode for RSA.
Drivers:
* Memory overwrite fix for vmx ghash.
* Add support for building ARM sha1-neon in Thumb2 mode.
* Reenable ARM ghash-ce code by adding import/export.
* Reenable img-hash by adding import/export.
* Add support for multiple cores in omap-aes.
* Add little-endian support for sha1-powerpc.
* Add Cavium HWRNG driver for ThunderX SoC.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Ananth Jasty (1):
PCI: quirk fixup for cavium invalid sriov link value.
Ard Biesheuvel (3):
crypto: arm/sha1-neon - add support for building in Thumb2 mode
crypto: arm/ghash-ce - add missing async import/export
crypto: arm/ghash - change internal cra_name to "__ghash"
Arnd Bergmann (1):
crypto: mv_cesa - remove NO_IRQ reference
Arvind Yadav (2):
hwrng: bcm2835 - handle of_iomap failures
crypto: caam - Unmap region obtained by of_iomap
Baoyou Xie (2):
crypto: caam - add missing header dependencies
crypto: sun4i-ss - mark sun4i_hash() static
Catalin Vasile (2):
crypto: caam - fix rfc3686(ctr(aes)) IV load
crypto: caam - fix sg dump
Corentin LABBE (17):
crypto: xts - fix a little typo
crypto: sun4i-ss - fix a few signed warning
crypto: sun4i-ss - unify update/final function
crypto: sun4i-ss - clean unused ss
crypto: sun4i-ss - fix spelling
crypto: sun4i-ss - Always use sun4i_tfm_ctx for storing pointer to dev ss
crypto: sun4i-ss - fix indentation of two crypto alg
hwrng: amd - Fix style problem with blank line
hwrng: amd - use the BIT macro
hwrng: amd - Be consitent with the driver name
hwrng: amd - Remove asm/io.h
hwrng: amd - release_region must be called after hwrng_unregister
hwrng: amd - Replace global variable with private struct
hwrng: amd - Access hardware via ioread32/iowrite32
hwrng: amd - Convert to new hwrng read() API
crypto: engine - move crypto engine to its own header
crypto: engine - permit to enqueue ashash_request
Daniel Thompson (1):
hwrng: core - Improve description of the ->read() interface
Dave Gerlach (1):
hwrng: omap - Only fail if pm_runtime_get_sync returns < 0
Eric Biggers (1):
crypto: doc - fix documentation for bulk registration functions
Fabio Estevam (1):
crypto: mxc-scc - check clk_prepare_enable() error
Gary R Hook (13):
crypto: ccp - Fix non-conforming comment style
crypto: ccp - Abstract PCI info for the CCP
crypto: ccp - Shorten the fields of the action structure
crypto: ccp - Refactoring: symbol cleanup
crypto: ccp - Refactor the storage block allocation code
crypto: ccp - Refactor code supporting the CCP's RNG
crypto: ccp - Refactor code to enable checks for queue space.
crypto: ccp - Let a v5 CCP provide the same function as v3
crypto: ccp - Add support for the RNG in a version 5 CCP
crypto: ccp - Enable DMA service on a v5 CCP
crypto: ccp - Enable use of the additional CCP
crypto: ccp - clean up data structure
crypto: ccp - Make syslog errors human-readable
Giovanni Cabiddu (1):
crypto: qat - fix leak on error path
Govindraj Raja (1):
crypto: img-hash - Add suspend resume hooks for img hash
Herbert Xu (4):
crypto: xor - Fix warning when XOR_SELECT_TEMPLATE is unset
crypto: algif_hash - Handle NULL hashes correctly
PCI: Fix cavium quirk compile failure with PCI_ATS off
Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
James Hartley (2):
crypto: img-hash - Add support for export and import
crypto: img-hash - log a successful probe
Jan Stancek (1):
crypto: testmgr - add guard to dst buffer for ahash_export
Lokesh Vutla (2):
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Add fallback support
Maksim Lukoshkov (2):
crypto: qat - fix constants table DMA
crypto: qat - fix incorrect accelerator mask for C3X devices
Marcelo Cerri (4):
crypto: ghash-generic - move common definitions to a new header file
crypto: vmx - Fix memory corruption caused by p8_ghash
crypto: sha1-powerpc - little-endian support
crypto: vmx - Ensure ghash-generic is enabled
Markus Elfring (7):
hwrng: pic32 - Delete unnecessary assignment for the field "owner"
crypto: caam - Use kmalloc_array() in ahash_setkey()
crypto: caam - Rename jump labels in ahash_setkey()
crypto: caam - Rename a jump label in five functions
crypto: caam - Return a value directly in caam_hash_cra_init()
crypto: caam - Delete an unnecessary initialisation in seven functions
crypto: caam - Move common error handling code in two functions
Martin Schwidefsky (1):
crypto: xor - skip speed test if the xor function is selected automatically
Masahiro Yamada (1):
crypto: squash lines for simple wrapper functions
Omer Khaliq (1):
hwrng: cavium - Add Cavium HWRNG driver for ThunderX SoC.
Ondrej Mosnáček (1):
crypto: gcm - Fix IV buffer size in crypto_gcm_setkey
PrasannaKumar Muralidharan (9):
hwrng: omap3-rom - Remove obsoleted functions
hwrng: Remove check for max less than 4 bytes
hwrng: tx4939 - Use devm_hwrng_register instead of hwrng_register
hwrng: pasemi - Migrate to managed API
hwrng: pasemi - Use linux/io.h instead of asm/io.h
hwrng: core - Allocate memory during module init
hwrng: amd - Migrate to managed API
hwrng: geode - Migrate to managed API
hwrng: geode - Use linux/io.h instead of asm/io.h
Quentin Lambert (3):
crypto: ixp4xx - Fix a "simple if" coding style warning
crypto: ixp4xx - Add missing npe_c release in error branches
crypto: ccp - add missing release in ccp_dmaengine_register
Romain Perier (3):
crypto: marvell - Update transformation context for each dequeued req
crypto: marvell - Don't overwrite default creq->state during initialization
crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req
Russell King (12):
crypto: caam - fix DMA API mapping leak
crypto: caam - ensure descriptor buffers are cacheline aligned
crypto: caam - incorporate job descriptor into struct ahash_edesc
crypto: caam - mark the hardware descriptor as cache line aligned
crypto: caam - replace sec4_sg pointer with array
crypto: caam - ensure that we clean up after an error
crypto: caam - check and use dma_map_sg() return code
crypto: caam - add ahash_edesc_alloc() for descriptor allocation
crypto: caam - move job descriptor initialisation to ahash_edesc_alloc()
crypto: caam - add ahash_edesc_add_src()
crypto: caam - get rid of tasklet
crypto: caam - avoid kernel warnings on probe failure
Stephan Mueller (3):
crypto: drbg - do not call drbg_instantiate in healt test
crypto: rsa - allow keys >= 2048 bits in FIPS mode
crypto: FIPS - allow tests to be disabled in FIPS mode
Sudip Mukherjee (1):
crypto: rockchip - use devm_add_action_or_reset()
Tero Kristo (14):
crypto: omap-sham - avoid executing tasklet where not needed
crypto: omap-sham - fix software fallback handling
crypto: omap-sham - fix SW fallback HMAC handling for omap2/omap3
crypto: omap-aes - use runtime_pm autosuspend for clock handling
crypto: omap-aes - fix crypto engine initialization order
crypto: omap-des - fix crypto engine initialization order
crypto: omap-sham - add context export/import stubs
crypto: omap-sham - align algorithms on word offset
crypto: omap-sham - rename sgl to sgl_tmp for deprecation
crypto: omap-sham - add support functions for sg based data handling
crypto: omap-sham - change the DMA threshold value to a define
crypto: omap-sham - convert driver logic to use sgs for data xmit
crypto: omap-sham - add support for export/import
crypto: omap-sham - shrink the internal buffer size
Thomas Petazzoni (4):
crypto: marvell - be explicit about destination in mv_cesa_dma_add_op()
crypto: marvell - remove unused parameter in mv_cesa_ahash_dma_add_cache()
crypto: marvell - turn mv_cesa_ahash_init() into a function returning void
crypto: marvell - make mv_cesa_ahash_cache_req() return bool
Tudor Ambarus (1):
crypto: caam - treat SGT address pointer as u64
Wei Yongjun (10):
crypto: ccp - Fix non static symbol warning
crypto: sun4i-ss - fix missing unlock on error in sun4i_hash()
crypto: drbg - fix error return code
hwrng: st - Fix missing clk_disable_unprepare() on error in st_rng_probe()
crypto: omap-des - fix error return code in omap_des_probe()
crypto: omap-aes - fix error return code in omap_aes_probe()
crypto: ccp - use kmem_cache_zalloc instead of kmem_cache_alloc/memset
hwrng: amd - Fix return value check in mod_init()
hwrng: geode - fix return value check in mod_init()
crypto: ccp - Fix return value check in ccp_dmaengine_register()
Will Thomas (4):
crypto: img-hash - Fix null pointer exception
crypto: img-hash - Fix hash request context
crypto: img-hash - Reconfigure DMA Burst length
crypto: img-hash - Fix set_reqsize call
Yanjiang Jin (1):
crypto: testmgr - fix !x==y confusion
Documentation/DocBook/crypto-API.tmpl | 38 +-
arch/arm/crypto/ghash-ce-glue.c | 26 +-
arch/arm/crypto/sha1-armv7-neon.S | 1 -
arch/powerpc/crypto/sha1-powerpc-asm.S | 13 +-
crypto/algif_hash.c | 73 +-
crypto/crct10dif_generic.c | 5 +-
crypto/crypto_engine.c | 187 +++-
crypto/drbg.c | 31 +-
crypto/gcm.c | 2 +-
crypto/ghash-generic.c | 13 +-
crypto/mcryptd.c | 7 +-
crypto/rsa_helper.c | 4 +-
crypto/testmgr.c | 24 +-
crypto/testmgr.h | 4 +
crypto/xor.c | 41 +-
crypto/xts.c | 2 +-
drivers/char/hw_random/Kconfig | 13 +
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/amd-rng.c | 140 +--
drivers/char/hw_random/bcm2835-rng.c | 5 +-
drivers/char/hw_random/cavium-rng-vf.c | 99 +++
drivers/char/hw_random/cavium-rng.c | 94 ++
drivers/char/hw_random/core.c | 37 +-
drivers/char/hw_random/geode-rng.c | 58 +-
drivers/char/hw_random/meson-rng.c | 3 -
drivers/char/hw_random/omap-rng.c | 4 +-
drivers/char/hw_random/omap3-rom-rng.c | 10 +-
drivers/char/hw_random/pasemi-rng.c | 39 +-
drivers/char/hw_random/pic32-rng.c | 1 -
drivers/char/hw_random/st-rng.c | 4 +-
drivers/char/hw_random/tx4939-rng.c | 11 +-
drivers/crypto/Kconfig | 3 +
drivers/crypto/caam/caamalg.c | 161 ++--
drivers/crypto/caam/caamhash.c | 581 ++++++------
drivers/crypto/caam/ctrl.c | 3 +
drivers/crypto/caam/desc.h | 6 -
drivers/crypto/caam/desc_constr.h | 17 +
drivers/crypto/caam/intern.h | 1 -
drivers/crypto/caam/jr.c | 26 +-
drivers/crypto/caam/regs.h | 8 +
drivers/crypto/caam/sg_sw_sec4.h | 2 +-
drivers/crypto/ccp/Makefile | 1 +
drivers/crypto/ccp/ccp-crypto-sha.c | 18 +-
drivers/crypto/ccp/ccp-dev-v3.c | 182 ++--
drivers/crypto/ccp/ccp-dev-v5.c | 1017 ++++++++++++++++++++++
drivers/crypto/ccp/ccp-dev.c | 113 ++-
drivers/crypto/ccp/ccp-dev.h | 312 +++++--
drivers/crypto/ccp/ccp-dmaengine.c | 11 +-
drivers/crypto/ccp/ccp-ops.c | 576 ++++++------
drivers/crypto/ccp/ccp-pci.c | 23 +-
drivers/crypto/hifn_795x.c | 12 +-
drivers/crypto/img-hash.c | 108 ++-
drivers/crypto/ixp4xx_crypto.c | 9 +-
drivers/crypto/marvell/cesa.c | 1 +
drivers/crypto/marvell/hash.c | 44 +-
drivers/crypto/marvell/tdma.c | 1 +
drivers/crypto/mv_cesa.c | 7 +-
drivers/crypto/mxc-scc.c | 4 +-
drivers/crypto/omap-aes.c | 141 +--
drivers/crypto/omap-des.c | 35 +-
drivers/crypto/omap-sham.c | 568 +++++++-----
drivers/crypto/qat/qat_c3xxx/adf_c3xxx_hw_data.h | 2 +-
drivers/crypto/qat/qat_common/adf_admin.c | 20 +-
drivers/crypto/qat/qat_common/qat_uclo.c | 8 +-
drivers/crypto/rockchip/rk3288_crypto.c | 6 +-
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 6 +-
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 68 +-
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 165 ++--
drivers/crypto/sunxi-ss/sun4i-ss.h | 2 +-
drivers/crypto/vmx/Kconfig | 1 +
drivers/crypto/vmx/ghash.c | 31 +-
drivers/pci/quirks.c | 11 +
include/crypto/algapi.h | 70 --
include/crypto/engine.h | 107 +++
include/crypto/ghash.h | 23 +
include/linux/ccp.h | 3 -
include/linux/hw_random.h | 4 +-
77 files changed, 3853 insertions(+), 1655 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: chacha counters in random.c
From: Stephan Mueller @ 2016-10-10 3:34 UTC (permalink / raw)
To: Sami Farin; +Cc: Theodore Ts'o, linux-crypto
In-Reply-To: <20161009171627.cr7eunq4h2rnj5s4@m.mifar.in>
Am Sonntag, 9. Oktober 2016, 20:16:27 CEST schrieb Sami Farin:
Hi Sami,
> commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
>
> + chacha20_block(&crng->state[0], out);
> + if (crng->state[12] == 0)
> + crng->state[13]++;
>
> Did you mean
> + if (++crng->state[12] == 0)
Please see chacha20_block at the end:
state[12]++;
I would guess that this is the increment you are looking for.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 0/3] Fix crypto/vmx/p8_ghash memory corruption
From: Herbert Xu @ 2016-10-10 2:16 UTC (permalink / raw)
To: Marcelo Cerri; +Cc: linux-crypto
In-Reply-To: <20161003150725.GF10133@gallifrey>
On Mon, Oct 03, 2016 at 12:07:25PM -0300, Marcelo Cerri wrote:
> Hi Herbert,
>
> Sorry for bothering you. I noticed you included two of the patches in
> the crypto-2.6 repository and the remaining one in cryptodev-2.6. Is
> that right? I thought all 3 patches would be included in the cruptodev
> repository.
I wanted the first two to go to stable as well so that's why
I split them up.
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
* [PATCH 6/6] crypto: arm64/aes-neon - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-neon.S | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index b93170e1cc93..85f07ead7c5c 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arch/arm64/crypto/aes-neon.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#define AES_ENTRY(func) ENTRY(neon_ ## func)
#define AES_ENDPROC(func) ENDPROC(neon_ ## func)
@@ -83,13 +84,13 @@
.endm
.macro do_block, enc, in, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in\().16b, \in\().16b, v15.16b /* ^round key */
tbl \in\().16b, {\in\().16b}, v13.16b /* ShiftRows */
sub_bytes \in
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -229,7 +230,7 @@
.endm
.macro do_block_2x, enc, in0, in1 rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -237,7 +238,7 @@
sub_bytes_2x \in0, \in1
tbl \in0\().16b, {\in0\().16b}, v13.16b /* ShiftRows */
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -254,7 +255,7 @@
.endm
.macro do_block_4x, enc, in0, in1, in2, in3, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -266,7 +267,7 @@
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
tbl \in2\().16b, {\in2\().16b}, v13.16b /* ShiftRows */
tbl \in3\().16b, {\in3\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -306,12 +307,16 @@
.text
.align 4
.LForward_ShiftRows:
- .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3
- .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb
+CPU_LE( .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3 )
+CPU_LE( .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb )
+CPU_BE( .byte 0xb, 0x6, 0x1, 0xc, 0x7, 0x2, 0xd, 0x8 )
+CPU_BE( .byte 0x3, 0xe, 0x9, 0x4, 0xf, 0xa, 0x5, 0x0 )
.LReverse_ShiftRows:
- .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb
- .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3
+CPU_LE( .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb )
+CPU_LE( .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3 )
+CPU_BE( .byte 0x3, 0x6, 0x9, 0xc, 0xf, 0x2, 0x5, 0x8 )
+CPU_BE( .byte 0xb, 0xe, 0x1, 0x4, 0x7, 0xa, 0xd, 0x0 )
.LForward_Sbox:
.byte 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] crypto: arm64/aes-ccm-ce: fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
index a2a7fbcacc14..3363560c79b7 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
.text
.arch armv8-a+crypto
@@ -19,7 +20,7 @@
*/
ENTRY(ce_aes_ccm_auth_data)
ldr w8, [x3] /* leftover from prev round? */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v0.16b}, [x0] /* load mac */
cbz w8, 1f
sub w8, w8, #16
eor v1.16b, v1.16b, v1.16b
@@ -31,7 +32,7 @@ ENTRY(ce_aes_ccm_auth_data)
beq 8f /* out of input? */
cbnz w8, 0b
eor v0.16b, v0.16b, v1.16b
-1: ld1 {v3.2d}, [x4] /* load first round key */
+1: ld1 {v3.16b}, [x4] /* load first round key */
prfm pldl1strm, [x1]
cmp w5, #12 /* which key size? */
add x6, x4, #16
@@ -41,17 +42,17 @@ ENTRY(ce_aes_ccm_auth_data)
mov v5.16b, v3.16b
b 4f
2: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x6], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x6], #16 /* load 2nd round key */
3: aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
-4: ld1 {v3.2d}, [x6], #16 /* load next round key */
+4: ld1 {v3.16b}, [x6], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
-5: ld1 {v4.2d}, [x6], #16 /* load next round key */
+5: ld1 {v4.16b}, [x6], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
- ld1 {v5.2d}, [x6], #16 /* load next round key */
+ ld1 {v5.16b}, [x6], #16 /* load next round key */
bpl 3b
aese v0.16b, v4.16b
subs w2, w2, #16 /* last data? */
@@ -60,7 +61,7 @@ ENTRY(ce_aes_ccm_auth_data)
ld1 {v1.16b}, [x1], #16 /* load next input block */
eor v0.16b, v0.16b, v1.16b /* xor with mac */
bne 1b
-6: st1 {v0.2d}, [x0] /* store mac */
+6: st1 {v0.16b}, [x0] /* store mac */
beq 10f
adds w2, w2, #16
beq 10f
@@ -79,7 +80,7 @@ ENTRY(ce_aes_ccm_auth_data)
adds w7, w7, #1
bne 9b
eor v0.16b, v0.16b, v1.16b
- st1 {v0.2d}, [x0]
+ st1 {v0.16b}, [x0]
10: str w8, [x3]
ret
ENDPROC(ce_aes_ccm_auth_data)
@@ -89,27 +90,27 @@ ENDPROC(ce_aes_ccm_auth_data)
* u32 rounds);
*/
ENTRY(ce_aes_ccm_final)
- ld1 {v3.2d}, [x2], #16 /* load first round key */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v3.16b}, [x2], #16 /* load first round key */
+ ld1 {v0.16b}, [x0] /* load mac */
cmp w3, #12 /* which key size? */
sub w3, w3, #2 /* modified # of rounds */
- ld1 {v1.2d}, [x1] /* load 1st ctriv */
+ ld1 {v1.16b}, [x1] /* load 1st ctriv */
bmi 0f
bne 3f
mov v5.16b, v3.16b
b 2f
0: mov v4.16b, v3.16b
-1: ld1 {v5.2d}, [x2], #16 /* load next round key */
+1: ld1 {v5.16b}, [x2], #16 /* load next round key */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-2: ld1 {v3.2d}, [x2], #16 /* load next round key */
+2: ld1 {v3.16b}, [x2], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-3: ld1 {v4.2d}, [x2], #16 /* load next round key */
+3: ld1 {v4.16b}, [x2], #16 /* load next round key */
subs w3, w3, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
@@ -120,47 +121,47 @@ ENTRY(ce_aes_ccm_final)
aese v1.16b, v4.16b
/* final round key cancels out */
eor v0.16b, v0.16b, v1.16b /* en-/decrypt the mac */
- st1 {v0.2d}, [x0] /* store result */
+ st1 {v0.16b}, [x0] /* store result */
ret
ENDPROC(ce_aes_ccm_final)
.macro aes_ccm_do_crypt,enc
ldr x8, [x6, #8] /* load lower ctr */
- ld1 {v0.2d}, [x5] /* load mac */
- rev x8, x8 /* keep swabbed ctr in reg */
+ ld1 {v0.16b}, [x5] /* load mac */
+CPU_LE( rev x8, x8 ) /* keep swabbed ctr in reg */
0: /* outer loop */
- ld1 {v1.1d}, [x6] /* load upper ctr */
+ ld1 {v1.8b}, [x6] /* load upper ctr */
prfm pldl1strm, [x1]
add x8, x8, #1
rev x9, x8
cmp w4, #12 /* which key size? */
sub w7, w4, #2 /* get modified # of rounds */
ins v1.d[1], x9 /* no carry in lower ctr */
- ld1 {v3.2d}, [x3] /* load first round key */
+ ld1 {v3.16b}, [x3] /* load first round key */
add x10, x3, #16
bmi 1f
bne 4f
mov v5.16b, v3.16b
b 3f
1: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x10], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x10], #16 /* load 2nd round key */
2: /* inner loop: 3 rounds, 2x interleaved */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-3: ld1 {v3.2d}, [x10], #16 /* load next round key */
+3: ld1 {v3.16b}, [x10], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-4: ld1 {v4.2d}, [x10], #16 /* load next round key */
+4: ld1 {v4.16b}, [x10], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
aese v1.16b, v3.16b
aesmc v1.16b, v1.16b
- ld1 {v5.2d}, [x10], #16 /* load next round key */
+ ld1 {v5.16b}, [x10], #16 /* load next round key */
bpl 2b
aese v0.16b, v4.16b
aese v1.16b, v4.16b
@@ -177,14 +178,14 @@ ENDPROC(ce_aes_ccm_final)
eor v0.16b, v0.16b, v2.16b /* xor mac with pt ^ rk[last] */
st1 {v1.16b}, [x0], #16 /* write output block */
bne 0b
- rev x8, x8
- st1 {v0.2d}, [x5] /* store mac */
+CPU_LE( rev x8, x8 )
+ st1 {v0.16b}, [x5] /* store mac */
str x8, [x6, #8] /* store lsb end of ctr (BE) */
5: ret
6: eor v0.16b, v0.16b, v5.16b /* final round mac */
eor v1.16b, v1.16b, v5.16b /* final round enc */
- st1 {v0.2d}, [x5] /* store mac */
+ st1 {v0.16b}, [x5] /* store mac */
add w2, w2, #16 /* process partial tail block */
7: ldrb w9, [x1], #1 /* get 1 byte of input */
umov w6, v1.b[0] /* get top crypted ctr byte */
--
2.7.4
^ permalink raw reply related
* [PATCH 4/6] crypto: arm64/sha2-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.
Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha2-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index 5df9d9d470ad..01cfee066837 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -85,7 +85,7 @@ ENTRY(sha2_ce_transform)
ld1 {v12.4s-v15.4s}, [x8]
/* load state */
- ldp dga, dgb, [x0]
+ ld1 {dgav.4s, dgbv.4s}, [x0]
/* load sha256_ce_state::finalize */
ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize]
@@ -148,6 +148,6 @@ CPU_LE( rev32 v19.16b, v19.16b )
b 1b
/* store new state */
-3: stp dga, dgb, [x0]
+3: st1 {dgav.4s, dgbv.4s}, [x0]
ret
ENDPROC(sha2_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] crypto: arm64/sha1-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.
Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha1-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 033aae6d732a..c98e7e849f06 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -78,7 +78,7 @@ ENTRY(sha1_ce_transform)
ld1r {k3.4s}, [x6]
/* load state */
- ldr dga, [x0]
+ ld1 {dgav.4s}, [x0]
ldr dgb, [x0, #16]
/* load sha1_ce_state::finalize */
@@ -144,7 +144,7 @@ CPU_LE( rev32 v11.16b, v11.16b )
b 1b
/* store new state */
-3: str dga, [x0]
+3: st1 {dgav.4s}, [x0]
str dgb, [x0, #16]
ret
ENDPROC(sha1_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/6] crypto: arm64/ghash-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.
Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-core.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index dc457015884e..f0bb9f0b524f 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -29,8 +29,8 @@
* struct ghash_key const *k, const char *head)
*/
ENTRY(pmull_ghash_update)
- ld1 {SHASH.16b}, [x3]
- ld1 {XL.16b}, [x1]
+ ld1 {SHASH.2d}, [x3]
+ ld1 {XL.2d}, [x1]
movi MASK.16b, #0xe1
ext SHASH2.16b, SHASH.16b, SHASH.16b, #8
shl MASK.2d, MASK.2d, #57
@@ -74,6 +74,6 @@ CPU_LE( rev64 T1.16b, T1.16b )
cbnz w0, 0b
- st1 {XL.16b}, [x1]
+ st1 {XL.2d}, [x1]
ret
ENDPROC(pmull_ghash_update)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/6] crypto: arm64/aes-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-cipher.c | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-cipher.c b/arch/arm64/crypto/aes-ce-cipher.c
index f7bd9bf0bbb3..50d9fe11d0c8 100644
--- a/arch/arm64/crypto/aes-ce-cipher.c
+++ b/arch/arm64/crypto/aes-ce-cipher.c
@@ -47,24 +47,24 @@ static void aes_cipher_encrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aese v0.16b, v2.16b ;"
" aesmc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aese v0.16b, v3.16b ;"
" aesmc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aese v0.16b, v1.16b ;"
" aesmc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aese v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -92,24 +92,24 @@ static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aesd v0.16b, v2.16b ;"
" aesimc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aesd v0.16b, v3.16b ;"
" aesimc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aesd v0.16b, v1.16b ;"
" aesimc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aesd v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -173,7 +173,12 @@ int ce_aes_expandkey(struct crypto_aes_ctx *ctx, const u8 *in_key,
u32 *rki = ctx->key_enc + (i * kwords);
u32 *rko = rki + kwords;
+#ifndef CONFIG_CPU_BIG_ENDIAN
rko[0] = ror32(aes_sub(rki[kwords - 1]), 8) ^ rcon[i] ^ rki[0];
+#else
+ rko[0] = rol32(aes_sub(rki[kwords - 1]), 8) ^ (rcon[i] << 24) ^
+ rki[0];
+#endif
rko[1] = rko[0] ^ rki[1];
rko[2] = rko[1] ^ rki[2];
rko[3] = rko[2] ^ rki[3];
--
2.7.4
^ permalink raw reply related
* [PATCH 0/6] crypto: arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-crypto, linux-arm-kernel, herbert
Cc: catalin.marinas, will.deacon, Ard Biesheuvel
As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
currently work, or have ever worked correctly when built for big endian. So this
series fixes all of them.
Each of these patches carries a fixes tag, and could be backported to stable.
However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
fix is compatible with, not the patch that introduced the algorithm. This is due
to the fact that the key schedules are incompatible between generic AES and the
arm64 Crypto Extensions implementation (but only when building for big endian)
This is not a problem in practice, but it does mean that the AES-CCM and AES in
EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
one that is compatible with the generic AES key schedule generation code (which
it currently no longer uses)
In any case, please apply with cc to stable.
Ard Biesheuvel (6):
crypto: arm64/aes-ce - fix for big endian
crypto: arm64/ghash-ce - fix for big endian
crypto: arm64/sha1-ce - fix for big endian
crypto: arm64/sha2-ce - fix for big endian
crypto: arm64/aes-ccm-ce: fix for big endian
crypto: arm64/aes-neon - fix for big endian
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
arch/arm64/crypto/aes-neon.S | 25 +++++----
arch/arm64/crypto/ghash-ce-core.S | 6 +--
arch/arm64/crypto/sha1-ce-core.S | 4 +-
arch/arm64/crypto/sha2-ce-core.S | 4 +-
6 files changed, 64 insertions(+), 53 deletions(-)
--
2.7.4
^ permalink raw reply
* chacha counters in random.c
From: Sami Farin @ 2016-10-09 17:16 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-crypto
commit e192be9d9a30555aae2ca1dc3aad37cba484cd4a
+ chacha20_block(&crng->state[0], out);
+ if (crng->state[12] == 0)
+ crng->state[13]++;
Did you mean
+ if (++crng->state[12] == 0)
?
--
Do what you love because life is too short for anything else.
https://samifar.in/
^ permalink raw reply
* Re: Observed a ecryptFS crash
From: xiakaixu @ 2016-10-09 7:12 UTC (permalink / raw)
To: tyhicks@canonical.com
Cc: liushuoran, linux-crypto@vger.kernel.org,
ecryptfs@vger.kernel.org, linux-kernel@vger.kernel.org,
Yaodongdong, Wangbintian, yingjindong, Yezongbo, likan (A)
In-Reply-To: <00B10D30F2BAA743B48953A4D86C96D54CB653@SZXEMI506-MBS.china.huawei.com>
ping...
> Hi Tyhicks,
>
> We observed a ecryptFS crash occasionally in Linux kernel 4.1.18. The call trace is attached below. Is it a known issue？ Look forward to hearing from you. Thanks in advance!
>
> [19314.529479s][pid:2694,cpu3,GAC_Executor[0]]Call trace:
> [19314.529510s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0000f3898>] do_raw_spin_lock+0x20/0x200
> [19314.529510s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc001031fb0>] _raw_spin_lock+0x28/0x34
> [19314.529541s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0003908e0>] selinux_inode_free_security+0x3c/0x94
> [19314.529541s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000386b04>] security_inode_free+0x2c/0x38
> [19314.529541s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0001fff88>] __destroy_inode+0x2c/0x180
> [19314.529571s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000201660>] destroy_inode+0x30/0xa0
> [19314.529571s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0002017d8>] evict+0x108/0x1c0
> [19314.529571s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000202588>] iput+0x184/0x258
> [19314.529602s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0002f27d0>] ecryptfs_evict_inode+0x30/0x3c
> [19314.529602s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc00020177c>] evict+0xac/0x1c0
> [19314.529602s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0002018d4>] dispose_list+0x44/0x5c
> [19314.529632s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000202d28>] evict_inodes+0xcc/0x12c
> [19314.529632s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0001e5d04>] generic_shutdown_super+0x58/0xe4
> [19314.529632s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0001e7164>] kill_anon_super+0x30/0x74
> [19314.529663s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0002f16a4>] ecryptfs_kill_block_super+0x24/0x54
> [19314.529663s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0001e6690>] deactivate_locked_super+0x60/0x8c
> [19314.529663s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0001e6754>] deactivate_super+0x98/0xa4
> [19314.529693s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000206d54>] cleanup_mnt+0x50/0xd0
> [19314.529693s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000206e48>] __cleanup_mnt+0x20/0x2c
> [19314.529693s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0000c1bac>] task_work_run+0xbc/0xf8
> [19314.529724s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0000a3e98>] do_exit+0x2d4/0xa14
> [19314.529724s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0000a56a8>] do_group_exit+0x60/0xf8
> [19314.529724s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc0000b26ac>] get_signal+0x284/0x598
> [19314.529754s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc00008950c>] do_signal+0x170/0x5b8
> [19314.529754s][pid:2694,cpu3,GAC_Executor[0]][<ffffffc000089be0>] do_notify_resume+0x70/0x78
> [19314.529785s][pid:2694,cpu3,GAC_Executor[0]]Code: aa0003f3 aa1e03e0 97fe7718 5289d5a0 (b9400661)
> [19314.529907s][pid:2694,cpu3,GAC_Executor[0]]---[ end trace 382e4b6264b035b5 ]---
> [19314.529907s][pid:2694,cpu3,GAC_Executor[0]]Kernel panic - not syncing: Fatal exception
>
> Regards,
> Shuoran
>
^ permalink raw reply
* Re: PEACE BE WITH YOU,
From: contact @ 2016-10-06 4:37 UTC (permalink / raw)
To: Recipients
Subject: Can I Trust You In This5 Days Project ?
Email ( dr.kpyj1958@gmail.com )
Dear Friend
My name is ATTORNEY KONO PETER , I really do not mean to waste your time. Considering the fact that this is a £36,000,000.00 British Pounds.deal shear rate 50/50 % and it's bank to bank wire trasaction within Five workind days.
I carefully contact you due to many Internet frauds nowadays.but i put my faith in God because all things in life is by risk but don't let me down now or after, This is Mr.Plaviashakunthala Lobo and his family was involved in plan crash 22nd of May 2010 in List of passengers on Air India Express flight that crash 32.Plaviashakunthala Lobo 33. Venishanikola Lobo
34. Vishalfloid Lobo (child) and all family died without any inheritance or next of kin so i want you to work together with me been an attorney so this is Mr.Plaviashakunthala Lobo account details.
Bank name: Bank of Africa
Bank Address: Cotonou Benin Republic
Account name: Plavia shakunthala Lobo
Account Number: 1103-8022-1351
Account Balance: £36,000,000.00 British Pounds (GBP)
Date of deposit: 19th December, 2009
Account officer : Bashirudeen Hussam
I was with Mr.Plaviashakunthala Lobo as a legal witness when this money was deposited as fixed deposit in 2009. Since his demise, I have visited this bank three times. Contact the bank and ask for the confirmation of his involvement in the plane crash.check the website: http://www.thehindu.com/news/national/list-of-passengers-on-air-india-express-flight/article435569.ece
Thanks
ATTORNEY KONO PETER
------------------------------------------
Disclaimer: This message transmitted with it are confidential and privileged. If you have received it in error, please notify the sender by return e-mail and delete this message from your system. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this e-mail is strictly prohibited.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH] crypto: caam: add support for iMX6UL
From: Rob Herring @ 2016-10-09 1:29 UTC (permalink / raw)
To: Marcus Folkesson
Cc: herbert, davem, mark.rutland, horia.geanta, tudor-dan.ambarus,
alexandru.porosanu, arnd, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20161004133259.GA30071@gmail.com>
On Tue, Oct 04, 2016 at 09:32:59AM -0400, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
> ---
> .../devicetree/bindings/crypto/fsl-sec4.txt | 20 +++++++++++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/crypto/caam/ctrl.c | 35 ++++++++++++----------
> 2 files changed, 40 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH] crypto: api - Remove no-op exit_ops code
From: Eric Biggers @ 2016-10-07 21:13 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Eric Biggers
crypto_exit_cipher_ops() and crypto_exit_compress_ops() are no-ops and
have been for a long time, so remove them.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
crypto/api.c | 20 ++------------------
crypto/cipher.c | 4 ----
crypto/compress.c | 4 ----
crypto/internal.h | 3 ---
4 files changed, 2 insertions(+), 29 deletions(-)
diff --git a/crypto/api.c b/crypto/api.c
index bbc147c..a88729f 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -310,24 +310,8 @@ static void crypto_exit_ops(struct crypto_tfm *tfm)
{
const struct crypto_type *type = tfm->__crt_alg->cra_type;
- if (type) {
- if (tfm->exit)
- tfm->exit(tfm);
- return;
- }
-
- switch (crypto_tfm_alg_type(tfm)) {
- case CRYPTO_ALG_TYPE_CIPHER:
- crypto_exit_cipher_ops(tfm);
- break;
-
- case CRYPTO_ALG_TYPE_COMPRESS:
- crypto_exit_compress_ops(tfm);
- break;
-
- default:
- BUG();
- }
+ if (type && tfm->exit)
+ tfm->exit(tfm);
}
static unsigned int crypto_ctxsize(struct crypto_alg *alg, u32 type, u32 mask)
diff --git a/crypto/cipher.c b/crypto/cipher.c
index 39541e0..94fa355 100644
--- a/crypto/cipher.c
+++ b/crypto/cipher.c
@@ -116,7 +116,3 @@ int crypto_init_cipher_ops(struct crypto_tfm *tfm)
return 0;
}
-
-void crypto_exit_cipher_ops(struct crypto_tfm *tfm)
-{
-}
diff --git a/crypto/compress.c b/crypto/compress.c
index c33f076..f2d5229 100644
--- a/crypto/compress.c
+++ b/crypto/compress.c
@@ -42,7 +42,3 @@ int crypto_init_compress_ops(struct crypto_tfm *tfm)
return 0;
}
-
-void crypto_exit_compress_ops(struct crypto_tfm *tfm)
-{
-}
diff --git a/crypto/internal.h b/crypto/internal.h
index 7eefcdb..f073204 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -76,9 +76,6 @@ struct crypto_alg *crypto_alg_mod_lookup(const char *name, u32 type, u32 mask);
int crypto_init_cipher_ops(struct crypto_tfm *tfm);
int crypto_init_compress_ops(struct crypto_tfm *tfm);
-void crypto_exit_cipher_ops(struct crypto_tfm *tfm);
-void crypto_exit_compress_ops(struct crypto_tfm *tfm);
-
struct crypto_larval *crypto_larval_alloc(const char *name, u32 type, u32 mask);
void crypto_larval_kill(struct crypto_alg *alg);
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH] crypto: skcipher - Remove unused crypto_lookup_skcipher() declaration
From: Eric Biggers @ 2016-10-07 21:13 UTC (permalink / raw)
To: herbert, davem; +Cc: linux-crypto, Eric Biggers
The definition of crypto_lookup_skcipher() was already removed in
commit 3a01d0ee2b99 ("crypto: skcipher - Remove top-level givcipher
interface"). So the declaration should be removed too.
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
include/crypto/internal/skcipher.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index a21a95e..95d2a18 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -74,8 +74,6 @@ static inline int crypto_grab_skcipher2(struct crypto_skcipher_spawn *spawn,
return crypto_grab_skcipher(spawn, name, type, mask);
}
-struct crypto_alg *crypto_lookup_skcipher(const char *name, u32 type, u32 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
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