Hi,
I would like to report issue with ccp-crypto.
When I issue modprobe command, it would not continue, without SIGINT
signal (ctrl+c).
If module is compiled in kernel, boot doesn't finish.
Looks like problem is that ecb(aes) selftest do not finish ?
kernel 5.10.1
smpboot: CPU0: AMD Athlon PRO
On Wed, Dec 16, 2020 at 11:32:44PM +0100, Jason A. Donenfeld wrote:
> Hi Eric,
>
> On Wed, Dec 16, 2020 at 9:48 PM Eric Biggers wrote:
> > By the way, if people are interested in having my ARM scalar implementation
> > of
> > BLAKE2s in the kernel too, I can send a patchset for that too. It jus
在 2020/12/17 4:10, Stephan Mueller 写道:
Am Mittwoch, dem 16.12.2020 um 10:39 +0800 schrieb yumeng:
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P128_N_SIZE 16
Do we truly need P-128? Besides, I do not see that
On Wed, Dec 16, 2020 at 10:07:38PM +, Nick Terrell wrote:
[...]
> It is very large. If it helps, in the commit message I’ve provided this link
> [0],
> which provides the diff between upstream zstd as-is and the imported zstd,
> which has been modified by the automated tooling to work in the k
Hi Eric,
On Wed, Dec 16, 2020 at 9:48 PM Eric Biggers wrote:
> By the way, if people are interested in having my ARM scalar implementation of
> BLAKE2s in the kernel too, I can send a patchset for that too. It just ended
> up
> being slower than BLAKE2b and SHA-1, so it wasn't as good for the u
> On Dec 16, 2020, at 10:50 AM, David Sterba wrote:
>
> On Wed, Dec 16, 2020 at 11:58:07AM +1100, Herbert Xu wrote:
>> On Wed, Dec 16, 2020 at 12:48:51AM +, Nick Terrell wrote:
>>>
>>> Thanks for the advice! The first zstd patches went through Herbert’s tree,
>>> which is
>>> why I’ve sen
On Tue, Dec 15, 2020 at 03:47:08PM -0800, Eric Biggers wrote:
> +// Execute one round of BLAKE2b by updating the state matrix v[0..15] in the
> +// NEON registers q0-q7. The message block is in q8..q15. The stack pointer
> +// points to a 32-byte aligned buffer containing a copy of q8 and q9, so
On Tue, Dec 15, 2020 at 03:47:03PM -0800, Eric Biggers wrote:
> This patchset adds a NEON implementation of BLAKE2b for 32-bit ARM.
> Patches 1-4 prepare for it by making some updates to the generic
> implementation, while patch 5 adds the actual NEON implementation.
>
> On Cortex-A7 (which these
Am Mittwoch, dem 16.12.2020 um 10:39 +0800 schrieb yumeng:
>
>
>
> > Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
> > >
> > > +/* size in bytes of the n prime */
> > > +#define HPRE_ECC_NIST_P128_N_SIZE 16
> >
> > Do we truly need P-128? Besides, I do not see that curve being
On Wed, Dec 16, 2020 at 11:58:07AM +1100, Herbert Xu wrote:
> On Wed, Dec 16, 2020 at 12:48:51AM +, Nick Terrell wrote:
> >
> > Thanks for the advice! The first zstd patches went through Herbert’s tree,
> > which is
> > why I’ve sent them this way.
>
> Sorry, but I'm not touch these patches a
Key Locker (KL) is Intel's new security feature that protects the AES key
at the time of data transformation. New AES SIMD instructions -- as a
successor of Intel's AES-NI -- are provided to encode an AES key and
reference it for the AES algorithm.
New instructions support 128/256-bit keys. While
The test validates the internal key to be the same in all CPUs.
It performs the validation again with the Suspend-To-RAM (ACPI S3) state.
Signed-off-by: Chang S. Bae
Cc: linux-ker...@vger.kernel.org
Cc: linux-kselft...@vger.kernel.org
---
tools/testing/selftests/x86/Makefile| 2 +-
tools/
When the system state switches to these sleep states, the internal key gets
reset. Since this system transition is transparent to userspace, the
internal key needs to be restored properly.
Key Locker provides a mechanism to back up the internal key in non-volatile
memory. The kernel requests a bac
Add a kernel config option to enable the feature (disabled by default) at
compile-time.
Also, add a new command-line parameter -- 'nokeylocker' to disable the
feature at boot-time.
Signed-off-by: Chang S. Bae
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
Hardware can load the internal key with randomization. random.trust_cpu
determines the use of the CPU's random number generator. Take the parameter
to use the CPU's internal key randomization.
The backup mechanism is required to distribute the key. It is the only
way to copy the (unknown) key valu
Key Locker internal key in a CPU state can be backed up in a platform
register. The backup can be also copied back to a CPU state. This mechanism
is useful to restore the key (after system sleep).
Add MSRs for the internal key backup, copy, and status check.
Signed-off-by: Chang S. Bae
Cc: x...@
Internal (Wrapping) Key is a new entity of Intel Key Locker feature. This
internal key is loaded in a software-inaccessible CPU state and used to
encode a data encryption key.
The kernel makes random data and loads it as the internal key in each CPU.
The data need to be invalidated as soon as the
Intel's Key Locker is a new security feature providing a mechanism to
protect a data encryption key when processing the Advanced Encryption
Standard algorithm.
Here we add it to the kernel/user ABI by enumerating the hardware
capability. E.g., /proc/cpuinfo: keylocker.
Also, define the feature-sp
Key Locker [1][2] is a new security feature available in new Intel CPUs to
protect data encryption keys for the Advanced Encryption Standard
algorithm. The protection limits the amount of time an AES key is exposed
in memory by sealing a key and referencing it with new AES instructions.
The new AE
Thanks for the patch.
On Wed, 2020-12-16 at 14:14 +0100, Geert Uytterhoeven wrote:
> The Intel Keem Bay Offload and Crypto Subsystem (OCS) is only present
> on
> Intel Keem Bay SoCs. Hence add a dependency on ARCH_KEEMBAY, to
> prevent
> asking the user about this driver when configuring a kernel
syzbot suspects this issue was fixed by commit:
commit 1d0e850a49a5b56f8f3cb51e74a11e2fedb96be6
Author: David Howells
Date: Fri Oct 16 12:21:14 2020 +
afs: Fix cell removal
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=128ceadf50
start commit: c85fb28b Merge tag '
The Intel Keem Bay Offload and Crypto Subsystem (OCS) is only present on
Intel Keem Bay SoCs. Hence add a dependency on ARCH_KEEMBAY, to prevent
asking the user about this driver when configuring a kernel without
Intel Keem Bay platform support.
While at it, fix a misspelling of "cipher".
Fixes:
From: Daniele Alessandrelli
Add maintainers for the Intel Keem Bay Offload Crypto Subsystem (OCS)
Hash Control Unit (HCU) crypto driver.
Signed-off-by: Daniele Alessandrelli
Acked-by: Declan Murphy
---
MAINTAINERS | 11 +++
1 file changed, 11 insertions(+)
diff --git a/MAINTAINERS b/
From: Daniele Alessandrelli
Add HMAC support to the Keem Bay OCS HCU driver, thus making it provide
the following additional transformations:
- hmac(sha256)
- hmac(sha384)
- hmac(sha512)
- hmac(sm3)
The Keem Bay OCS HCU hardware does not allow "context-switch" for HMAC
operations, i.e., it does
From: Daniele Alessandrelli
Add optional support of sha224 and hmac(sha224).
Co-developed-by: Declan Murphy
Signed-off-by: Declan Murphy
Signed-off-by: Daniele Alessandrelli
---
drivers/crypto/keembay/Kconfig| 12
drivers/crypto/keembay/keembay-ocs-hcu-core.c | 63 ++
From: Declan Murphy
Add support for the Hashing Control Unit (HCU) included in the Offload
Crypto Subsystem (OCS) of the Intel Keem Bay SoC, thus enabling
hardware-accelerated hashing on the Keem Bay SoC for the following
algorithms:
- sha256
- sha384
- sha512
- sm3
The driver is composed of two
From: Declan Murphy
Add device-tree bindings for the Intel Keem Bay Offload Crypto Subsystem
(OCS) Hashing Control Unit (HCU) crypto driver.
Signed-off-by: Declan Murphy
Signed-off-by: Daniele Alessandrelli
Acked-by: Mark Gross
Reviewed-by: Rob Herring
---
.../crypto/intel,keembay-ocs-hcu.y
The Intel Keem Bay SoC has an Offload Crypto Subsystem (OCS) featuring a
Hashing Control Unit (HCU) for accelerating hashing operations.
This driver adds support for such hardware thus enabling hardware-accelerated
hashing on the Keem Bay SoC for the following algorithms:
- sha224 and hmac(sha224)
On 2020/6/23 23:04, Bjorn Helgaas wrote:
> On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
>> Have studied _DSM method, two issues we met comparing using quirk.
>>
>> 1. Need change definition of either pci_host_bridge or pci_dev, like adding
>> member can_stall,
>> while pci system d
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
30 matches
Mail list logo
