WireGuard and IPsec both typically operate on input blocks that are
~1420 bytes in size, given the default Ethernet MTU of 1500 bytes and
the overhead of the VPN metadata.
Many aead and sckipher implementations are optimized for power-of-2
block sizes, and whether they perform well when operating
Some tcrypt enhancements that I have been using locally to test and
benchmark crypto algorithms on the command line using KVM:
- allow tcrypt.ko to be builtin and defer its initialization to late_initcall
- add 1420 byte blocks to the list of benchmarked block sizes for AEADs and
skciphers, to ge
Commit c4741b2305979 ("crypto: run initcalls for generic implementations
earlier") converted tcrypt.ko's module_init() to subsys_initcall(), but
this was unintentional: tcrypt.ko currently cannot be built into the core
kernel, and so the subsys_initcall() gets converted into module_init()
under the
When working on crypto algorithms, being able to run tcrypt quickly
without booting an entire Linux installation can be very useful. For
instance, QEMU/kvm can be used to boot a kernel from the command line,
and having tcrypt.ko builtin would allow tcrypt to be executed to run
benchmarks, or to run
Fix aead auth setting key process error. if use soft shash function, driver
need to use digest size replace of the user input key length.
Signed-off-by: Kai Ye
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/h
I've been looking at the patch and it looks like it should work. Having
numbers to backup the performance in the pure-software version and with
HW acceleration would _very_ nice to have.
On 2020-11-07 19:53:32 [+1300], Barry Song wrote:
> index fbb7829..73f04de 100644
> --- a/mm/zswap.c
> +++ b/mm
> -Original Message-
> From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de]
> Sent: Monday, November 9, 2020 11:29 PM
> To: Song Bao Hua (Barry Song)
> Cc: linux...@kvack.org; linux-crypto@vger.kernel.org;
> a...@linux-foundation.org; Linuxarm ; fanghao (A)
> ; linux-ker...@vger
This series introduces crypto(CPT) drivers(PF & VF) for Marvell OcteonTX2
CN96XX Soc.
OcteonTX2 SOC's resource virtualization unit (RVU) supports multiple
physical and virtual functions. Each of the PF/VF's functionality is
determined by what kind of resources are attached to it. When the CPT
bloc
On OcteonTX2 SoC, the admin function (AF) is the only one with all
priviliges to configure HW and alloc resources, PFs and it's VFs
have to request AF via mailbox for all their needs. This patch adds
a mailbox interface for CPT PFs and VFs to allocate resources
for cryptography. It also adds hardwa
Adds 'sriov_configure' to enable/disable virtual functions (VFs).
Also Initializes VF<=>PF mailbox IRQs, register handlers for
processing these mailbox messages.
Admin function (AF) handles resource allocation and configuration for
PFs and their VFs. PFs request the AF directly, via mailboxes.
Unl
Adds skeleton for the Marvell OcteonTX2 CPT physical function
driver which includes probe, PCI specific initialization and
hardware register defines.
RVU defines are present in AF driver
(drivers/net/ethernet/marvell/octeontx2/af), header files from
AF driver are included here to avoid duplication.
In the resource virtualization unit (RVU) each of the PF and AF
(admin function) share a 64KB of reserved memory region for
communication. This patch initializes PF <=> AF mailbox IRQs,
registers handlers for processing these communication messages.
Signed-off-by: Suheil Chandran
Signed-off-by: L
On OcteonTX2 platform CPT instruction enqueue and NIX
packet send are only possible via LMTST operations which
uses LDEOR instruction. This patch moves lmt flush
function from OcteonTX2 nic driver to include/linux/soc
since it will be used by OcteonTX2 CPT and NIC driver for
LMTST.
Signed-off-by:
Add entries to debugfs at /sys/kernel/debug/octeontx2/cpt.
cpt_pc: dump cpt performance HW registers.
Usage:
cat /sys/kernel/debug/octeontx2/cpt/cpt_pc
cpt_ae_sts: show cpt asymmetric engines current state
Usage:
cat /sys/kernel/debug/octeontx2/cpt/cpt_ae_sts
cpt_se_sts: show cpt symmetric engin
Add support for the Marvell OcteonTX2 CPT virtual function
driver. This patch includes probe, PCI specific initialization
and interrupt handling.
Signed-off-by: Suheil Chandran
Signed-off-by: Lukasz Bartosik
Signed-off-by: Srujana Challa
---
drivers/crypto/marvell/octeontx2/Makefile | 4
Attach LFs to CPT VF to process the crypto requests and register
LF interrupts.
Signed-off-by: Suheil Chandran
Signed-off-by: Lukasz Bartosik
Signed-off-by: Srujana Challa
---
drivers/crypto/marvell/octeontx2/Makefile | 2 +-
.../marvell/octeontx2/otx2_cpt_common.h | 3 +
.../mar
CPT includes microcoded GigaCypher symmetric engines(SEs), IPsec
symmetric engines(IEs), and asymmetric engines (AEs).
Each engine receives CPT instructions from the engine groups it has
subscribed to. This patch loads microcode, configures three engine
groups(one for SEs, one for IEs and one for A
CPT RVU Local Functions(LFs) needs to be attached to the
PF/VF to submit the instructions to CPT.
This patch adds the interface to initialize and attach
the LFs. It also adds interface to register the LF's
interrupts.
Signed-off-by: Suheil Chandran
Signed-off-by: Lukasz Bartosik
Signed-off-by: S
Adds support to get engine capabilities and adds a new mailbox
to share capabilities with VF driver.
Signed-off-by: Suheil Chandran
Signed-off-by: Srujana Challa
---
.../marvell/octeontx2/otx2_cpt_common.h | 36
.../marvell/octeontx2/otx2_cpt_reqmgr.h | 51 ++
drivers/cry
CPT offload module utilises the linux crypto framework to offload
crypto processing. This patch registers supported algorithms by
calling registration functions provided by the kernel crypto API.
The module currently supports:
- AES block cipher in CBC,ECB,XTS and CFB mode.
- 3DES block cipher in
In the public_key.h file, the #include is not necessary
Fixes: 215525639631a("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Cc: Tianjia Zhang
Signed-off-by: Dawning
---
include/crypto/public_key.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/crypto/public_key.h b/
On Tue, Nov 03, 2020 at 06:49:23PM +, Daniele Alessandrelli wrote:
> 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
>
On Mon, Nov 09, 2020 at 09:31:41AM +0100, Ard Biesheuvel wrote:
> Commit c4741b2305979 ("crypto: run initcalls for generic implementations
> earlier") converted tcrypt.ko's module_init() to subsys_initcall(), but
> this was unintentional: tcrypt.ko currently cannot be built into the core
> kernel,
On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
You just keep resedning this crap, don't you? Haven't you been told
multiple times to provide a proper kernel API by now?
You do consistently ask for a shim layer, but you haven’t explained
what we gain by diverging from the documented and
Dear Linux folks,
By mistake I built `XFRM_ESP` into the Linux kernel, resulting in
CONFIG_CRYPTO_SEQIV=y
CONFIG_CRYPTO_ECHAINIV=y
and also the Jitterentropy RNG to be built in.
CRYPTO_JITTERENTROPY=y
So, on the Asus F2A85-M PRO starting Linux 4.10-rc3 with
`initcall_debug`, the
On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote:
> This rfc will describe
> An upcoming treewide cleanup.
> How clang tooling was used to programatically do the clean up.
> Solicit opinions on how to generally use clang tooling.
>
> The clang warning -Wextra-semi-stmt produces about 10k w
Instead of copying the calculated authentication tag to memory and
calling crypto_memneq() to verify it, use vector bytewise compare and
min across vector instructions to decide whether the tag is valid. This
is more efficient, and given that the tag is only transiently held in a
NEON register, it
27 matches
Mail list logo
