On Mon, Dec 14, 2020 at 12:49:27PM -0800, Linus Torvalds wrote:
> The pain just isn't worth it, but more importantly, you simply need to
> get your workflow in order, and not send me completely untested
> garbage that hasn't even been compiled.
I have now more bandwidth. It was mostly eaten by SGX
On 15/12/2020 04:41, Eric Biggers wrote:
> On Mon, Dec 14, 2020 at 10:28:19AM +0800, Tony W Wang-oc wrote:
>> On 12/12/2020 01:43, Eric Biggers wrote:
>>> On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
On
Hi all,
After merging the ceph tree, today's linux-next build (x86_64
allmodconfig) failed like this:
net/ceph/messenger_v2.c:13:10: fatal error: crypto/sha.h: No such file or
directory
13 | #include
| ^~
Caused by commit
cd1a677cad99 ("libceph, ceph: implement
Hi Linus,
On Mon, 14 Dec 2020 13:05:51 -0800 Linus Torvalds
wrote:
>
> On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds
> wrote:
> >
> > I suspect the fix is trivial (change the "," to "|"), but I will not
> > be pulling this - or anything else that hasn't been in linux-next -
> > from you this
There are two issues with the management of the kernel thread to gather
entropy:
* it can terminate also if the rng is removed, and in this case it doesn't
synchronize with kthread_should_stop(), but it directly sets hwrng_fill
to NULL. If this happens after the NULL check but before kthread_st
On Mon, Dec 14, 2020 at 12:49 PM Linus Torvalds
wrote:
>
> I suspect the fix is trivial (change the "," to "|"), but I will not
> be pulling this - or anything else that hasn't been in linux-next -
> from you this merge window.
It looks like Stephen Rothwell saw it in next yesterday, and fixed it
The pull request you sent on Mon, 14 Dec 2020 16:55:16 +1100:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9e4b0d55d84a66dbfede56890501dc96e696059c
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Mon, Dec 14, 2020 at 2:04 AM David Howells wrote:
>
> Here's a set of minor fixes/cleanups that I've collected from various
> people for the next merge window.
This doesn't even build.
And no, that's not because of some merge error on my part. Just to
verify, I tried to build the head of what
On Mon, Dec 14, 2020 at 10:28:19AM +0800, Tony W Wang-oc wrote:
> On 12/12/2020 01:43, Eric Biggers wrote:
> > On Fri, Dec 11, 2020 at 07:29:04PM +0800, Tony W Wang-oc wrote:
> >> The driver crc32c-intel match CPUs supporting X86_FEATURE_XMM4_2.
> >> On platforms with Zhaoxin CPUs supporting this X
On Mon, Dec 14, 2020 at 01:25:20PM +1100, Herbert Xu wrote:
> On Sun, Dec 13, 2020 at 06:23:06PM -0800, Eric Biggers wrote:
> >
> > This part doesn't seem to be true, since the chacha implementations don't
> > implement the "output IV" thing. It's only cbc and ctr that do (or at least
> > those ar
Ciphers produce invalid results on BE.
Key and IV need to be written in LE.
Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto
accelerator")
Cc:
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 12 ++--
1 file changed,
Allwinner A10 and A13 SoC have a version of the SS which produce
invalid IV in IVx register.
Instead of adding a variant for those, let's convert SS to produce IV
directly from data.
Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto
accelerator")
Cc:
Signed-off-by: C
This patch enable to access usage stats for each algorithm.
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/Kconfig | 9
.../allwinner/sun4i-ss/sun4i-ss-cipher.c | 20 +++
.../crypto/allwinner/sun4i-ss/sun4i-ss-core.c | 52 +++
.../crypto/al
This patchs fixes some remaining style issue.
Signed-off-by: Corentin Labbe
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 3 ---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-prng.c | 1 +
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/dri
With the recent kmap change, some tests which were conditional on
CONFIG_DEBUG_HIGHMEM now are enabled by default.
This permit to detect a problem in sun4i-ss usage of kmap.
sun4i-ss uses two kmap via sg_miter (one for input, one for output), but
using two kmap at the same time is hard:
"the order
The need_fallback is never initialized and seem to be always true at runtime.
So all hardware operations are always bypassed.
Fixes: 0ae1f46c55f87 ("crypto: sun4i-ss - fallback when length is not multiple
of blocksize")
Cc:
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun4i-ss/su
The optimized cipher function need length multiple of 4 bytes.
But it get sometimes odd length.
This is due to SG data could be stored with an offset.
So the fix is to check also if the offset is aligned with 4 bytes.
Fixes: 6298e948215f2 ("crypto: sunxi-ss - Add Allwinner Security System crypto
Hello
For help testing on "crypto: sun4i-ss - Fix sparse endianness markers",
I have added "stats" support like other allwinner's crypto drivers.
Seeing stats showed a clear problem, the ciphers function were not used
at all.
This is due to the not-inialized need_fallback which is "init" as true
e
When running the non-optimized cipher function, SS produce partial random
output.
This is due to linearize buffers being reseted after each loop.
For preserving stack, instead of moving them back to start of function,
I move them in sun4i_ss_ctx.
Fixes: 8d3bcb9900ca ("crypto: sun4i-ss - reduce st
Hi Mark,
Thanks for the review.
On Thu, 2020-11-19 at 15:15 -0800, mark gross wrote:
> I don't know the crypto domain well but.
>
> my main feedback is:
>
> * can we remove the sha224 config option and just have it enabled?
Having SHA224 optional (and disabled by default) was a request from
In
Hi all,
I've been looking into a CAAM RNG issue for a while, where I could need
some input from people knowing the CAAM hardware better than I do.
Basically the issue is that on some i.MX6 units the RNG functionality
sometimes fails with this error:
caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60:
On 12/14/20 8:04 AM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When trying to disable the block we bitwise or the control
> register with value zero. This will leave the block always turned on.
> Fix this by setting the corresponding bit to zero.
>
> Fixes: c83d45d5685f ("hwrng
On 2020-12-14 8:04 a.m., matthias@kernel.org wrote:
> From: Matthias Brugger
>
> We are calling the same code for enable and disable the block in various
> parts of the driver. Put that code into a new function to reduce code
> duplication.
Patch needs to be regenerated after most of PATCH
On 12/14/20 8:04 AM, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> We are calling the same code for enable and disable the block in various
> parts of the driver. Put that code into a new function to reduce code
> duplication.
>
> Signed-off-by: Matthias Brugger
>
> ---
>
> dri
On 2020-12-14 8:04 a.m., matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When trying to disable the block we bitwise or the control
> register with value zero. This will leave the block always turned on.
> Fix this by setting the corresponding bit to zero.
>
> Fixes: c83d45d5685f ("
On 12/7/2020 11:00 AM, Allen Pais wrote:
> From: Allen Pais
>
> In preparation for unconditionally passing the
> struct tasklet_struct pointer to all tasklet
> callbacks, switch to using the new tasklet_setup()
> and from_tasklet() to pass the tasklet pointer explicitly.
>
> Signed-off-by: Romai
From: Matthias Brugger
When trying to disable the block we bitwise or the control
register with value zero. This will leave the block always turned on.
Fix this by setting the corresponding bit to zero.
Fixes: c83d45d5685f ("hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver")
Signed-off-by: Ma
From: Matthias Brugger
We are calling the same code for enable and disable the block in various
parts of the driver. Put that code into a new function to reduce code
duplication.
Signed-off-by: Matthias Brugger
---
drivers/char/hw_random/iproc-rng200.c | 37 ---
1 fil
On Thu, 10 Dec 2020 14:03:15 -0600, Rob Herring wrote:
> PicoXcell has had nothing but treewide cleanups for at least the last 8
> years and no signs of activity. The most recent activity is a yocto vendor
> kernel based on v3.0 in 2015.
>
> Cc: Jamie Iles
> Cc: linux-crypto@vger.kernel.org
> Sig
Remove dev_err() messages after platform_get_irq*() failures.
drivers/crypto/inside-secure/safexcel.c: line 1161 is redundant
because platform_get_irq() already prints an error
Generated by: scripts/coccinelle/api/platform_get_irq.cocci
Signed-off-by: Tian Tao
---
drivers/crypto/inside-secure/s
:17:37 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
tags/keys-fixes-20201214
for you to fetch changes up to 1b91ea77dfeb2c5924ab940f2e43177c78a37d8f:
certs: Replace K{U,G}IDT_INIT() wi
31 matches
Mail list logo
