RFC series for Chelsio Inline TLS driver (chtls.ko)
Driver use the ULP infrastructure to register chtls as Inline TLS ULP.
Chtls use TCP Sockets to transmit and receive TLS record. TCP proto_ops
is extended to offload TLS record.
T6 adapter provides the following features:
-TLS record off
added tls_device structure to register Inline TLS
drivers with net/tls
Signed-off-by: Atul Gupta
---
include/net/tls.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/include/net/tls.h b/include/net/tls.h
index 936cfc5..2a9f392 100644
--- a/include/net/tls.h
+++ b/incl
Signed-off-by: Atul Gupta
---
include/linux/netdev_features.h | 2 ++
net/core/ethtool.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index b1b0ca7..e1a33b7 100644
--- a/include/linux/netdev_features.h
+++ b/i
Signed-off-by: Atul Gupta
---
net/tls/tls_main.c | 113 +
1 file changed, 113 insertions(+)
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index e07ee3a..10a6d5d 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -38,6 +38,7 @@
Inline TLS state, connection management. Supporting macros definition.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls.h| 487
drivers/crypto/chelsio/chtls/chtls_cm.h | 203 +
2 files changed, 690 insertions(+)
create mode 100644
Key area size in hw-config file. CPL struct for TLS request
and response. Work request for Inline TLS.
Signed-off-by: Atul Gupta
---
drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 121 ++-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 2 +
drivers/net/ethernet/chelsio/cxgb4/
Define macro for TLS Key context
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chcr_algo.h | 42 +
drivers/crypto/chelsio/chcr_core.h | 55 +-
2 files changed, 96 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/chel
Program the tx and rx key on chip.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_hw.c | 394
1 file changed, 394 insertions(+)
create mode 100644 drivers/crypto/chelsio/chtls/chtls_hw.c
diff --git a/drivers/crypto/chelsio/chtls/chtls_hw.c
b/
Read FW capability. Read key area size. Dump the TLS record count.
Signed-off-by: Atul Gupta
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 18 +++-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c| 32 +--
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 7 ++
drivers/net/
TLS handler for record transmit and receive.
Create Inline TLS work request and post to FW.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_io.c | 1867 +++
1 file changed, 1867 insertions(+)
create mode 100644 drivers/crypto/chelsio/chtls/chtls_io.c
CPL handlers for TLS session, record transmit and receive.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_cm.c | 2045 +++
net/ipv4/tcp_minisocks.c|1 +
2 files changed, 2046 insertions(+)
create mode 100644 drivers/crypto/chelsi
Entry for Inline TLS as another driver dependent on cxgb4 and chcr
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/Kconfig| 11 +++
drivers/crypto/chelsio/Makefile | 1 +
drivers/crypto/chelsio/chtls/Makefile | 4
3 files changed, 16 insertions(+)
create mode 1
Add new uld driver for Inline TLS support. Register ULP for chtls.
Setsockopt to program key on chip. support AES GCM key size 128.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls_main.c | 619 ++
include/uapi/linux/tls.h | 1 +
2 f
Move the AES inverse S-box to the .rodata section
where it is safe from abuse by speculation.
Signed-off-by: Jinbum Park
---
arch/arm/crypto/aes-cipher-core.S | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/crypto/aes-cipher-core.S
b/arch/arm/cr
On Sun, Dec 03, 2017 at 12:31:01PM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 4131d5166185d0d75b5f1d4bf362a9e0bac05598
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
Hi all,
On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
> > Hi Jeffrey,
> >
> > I see you wrote the SPECK implementation in Crypto++, and you are treating
> > the
> > words as big endian.
> >
> > Do you have a reference for this being the "correct" order? Unfortunately
> > the
>
From: Atul Gupta
Date: Mon, 12 Feb 2018 17:33:48 +0530
> + /* When calling get_netdev, the HW vendor's driver should return the
> + * net device of device @device at port @port_num or NULL if such
> + * a net device doesn't exist
> + */
> + struct net_device *(*netdev)(stru
From: Atul Gupta
Date: Mon, 12 Feb 2018 17:34:28 +0530
> +static int get_tls_prot(struct sock *sk)
> +{
> + struct tls_context *ctx = tls_get_ctx(sk);
> + struct net_device *netdev;
> + struct tls_device *dev;
> +
> + /* Device bound to specific IP */
> + if (inet_sk(sk)->inet
Use macro operations to merge implemetations of INITIAL_BLOCKS,
since they differ by only a small handful of lines.
Use macro counter \@ to simplify implementation.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 298 ++
1 file changed, 48
Macro-ify function save and restore. These will be used in new functions
added for scatter/gather update operations.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 53 ++-
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/arc
Reduce code duplication by introducting GCM_INIT macro. This macro
will also be exposed as a function for implementing scatter/gather
support, since INIT only needs to be called once for the full
operation.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 84 +++---
Merge encode and decode tag calculations in GCM_COMPLETE macro.
Scatter/gather routines will call this once at the end of encryption
or decryption.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 172 ++
1 file changed, 63 insertions(+), 109
This patch set refactors the x86 aes/gcm SSE crypto routines to
support true scatter/gather by adding gcm_enc/dec_update methods.
The layout is:
* First 5 patches refactor the code to use macros, so changes only
need to be applied once for encode and decode. There should be no
functional cha
Prepare to handle partial blocks between scatter/gather calls.
For the last partial block, we only want to calculate the aadhash
in GCM_COMPLETE, and a new partial block macro will handle both
aadhash update and encrypting partial blocks between calls.
Signed-off-by: Dave Watson
---
arch/x86/cry
AAD hash only needs to be calculated once for each scatter/gather operation.
Move it to its own macro, and call it from GCM_INIT instead of
INITIAL_BLOCKS.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 71 ---
1 file changed, 43 insertions
Fill in aadhash, aadlen, pblocklen, curcount with appropriate values.
pblocklen, aadhash, and pblockenckey are also updated at the end
of each scatter/gather operation, to be carried over to the next
operation.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 51 +++
Before this diff, multiple calls to GCM_ENC_DEC will
succeed, but only if all calls are a multiple of 16 bytes.
Handle partial blocks at the start of GCM_ENC_DEC, and update
aadhash as appropriate.
The data offset %r11 is also updated after the partial block.
Signed-off-by: Dave Watson
---
arc
We can fast-path any < 16 byte read if the full message is > 16 bytes,
and shift over by the appropriate amount. Usually we are
reading > 16 bytes, so this should be faster than the READ_PARTIAL
macro introduced in b20209c91e2 for the average case.
Signed-off-by: Dave Watson
---
arch/x86/crypto
Make a macro for the main encode/decode routine. Only a small handful
of lines differ for enc and dec. This will also become the main
scatter/gather update routine.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 293 +++---
1 file changed, 1
HashKey computation only needs to happen once per scatter/gather operation,
save it between calls in gcm_context struct instead of on the stack.
Since the asm no longer stores anything on the stack, we can use
%rsp directly, and clean up the frame save/restore macros a bit.
Hashkeys actually only
Add gcmaes_en/decrypt_sg routines, that will do scatter/gather
by sg. Either src or dst may contain multiple buffers, so
iterate over both at the same time if they are different.
If the input is the same as the output, iterate only over one.
Currently both the AAD and TAG must be linear, so copy t
The asm macros are all set up now, introduce entry points.
GCM_INIT and GCM_COMPLETE have arguments supplied, so that
the new scatter/gather entry points don't have to take all the
arguments, and only the ones they need.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 116 ++
Introduce a gcm_context_data struct that will be used to pass
context data between scatter/gather update calls. It is passed
as the second argument (after crypto keys), other args are
renumbered.
Signed-off-by: Dave Watson
---
arch/x86/crypto/aesni-intel_asm.S | 115 +--
On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers wrote:
> Hi all,
>
> On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
>> > Hi Jeffrey,
>> >
>> > I see you wrote the SPECK implementation in Crypto++, and you are treating
>> > the
>> > words as big endian.
>> >
>> > Do you have a refer
In case the probe of the clock is deferred, we would assume it is
optional. This is wrong, so defer the probe of this driver until
the clock is available.
Fixes: 791af4f4907a ("hwrng: bcm2835 - Manage an optional clock")
Signed-off-by: Stefan Wahren
---
drivers/char/hw_random/bcm2835-rng.c | 2 +
Hi Jeff,
On Mon, Feb 12, 2018 at 02:57:06PM -0500, Jeffrey Walton wrote:
> On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers wrote:
> > Hi all,
> >
> > On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote:
> >> > Hi Jeffrey,
> >> >
> >> > I see you wrote the SPECK implementation in Crypto++
On 02/12/2018 12:11 PM, Stefan Wahren wrote:
> In case the probe of the clock is deferred, we would assume it is
> optional. This is wrong, so defer the probe of this driver until
> the clock is available.
>
> Fixes: 791af4f4907a ("hwrng: bcm2835 - Manage an optional clock")
> Signed-off-by: Stefa
Hi Dave,
On 02/12/2018 11:51 AM, Dave Watson wrote:
> +static int gcmaes_encrypt_sg(struct aead_request *req, unsigned int assoclen,
> + u8 *hash_subkey, u8 *iv, void *aes_ctx)
>
> +static int gcmaes_decrypt_sg(struct aead_request *req, unsigned int assoclen,
> +
Add a generic implementation of Speck, including the Speck128 and
Speck64 variants. Speck is a lightweight block cipher that can be much
faster than AES on processors that don't have AES instructions.
We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
option for dm-crypt and fsc
Add an ARM NEON-accelerated implementation of Speck-XTS. It operates on
128-byte chunks at a time, i.e. 8 blocks for Speck128 or 16 blocks for
Speck64. Each 128-byte chunk goes through XTS preprocessing, then is
encrypted/decrypted (doing one cipher round for all the blocks, then the
next round,
Add test vectors for Speck128-XTS, generated in userspace using C code.
The inputs were borrowed from the AES-XTS test vectors.
Both xts(speck128-generic) and xts-speck128-neon pass these tests.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 9 +
crypto/testmgr.h | 687 +++
Add test vectors for Speck64-XTS, generated in userspace using C code.
The inputs were borrowed from the AES-XTS test vectors, with key lengths
adjusted.
xts-speck64-neon passes these tests. However, they aren't currently
applicable for the generic XTS template, as that only supports a 128-bit
bl
Hello,
This series adds Speck support to the crypto API, including the Speck128
and Speck64 variants. Speck is a lightweight block cipher that can be
much faster than AES on processors that don't have AES instructions.
We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an
option f
Export the Speck constants and transform context and the ->setkey(),
->encrypt(), and ->decrypt() functions so that they can be reused by the
ARM NEON implementation of Speck-XTS. The generic key expansion code
will be reused because it is not performance-critical and is not
vectorizable, while th
Am Montag, 12. Februar 2018, 20:51:28 CET schrieb Dave Watson:
Hi Dave,
> Add gcmaes_en/decrypt_sg routines, that will do scatter/gather
> by sg. Either src or dst may contain multiple buffers, so
> iterate over both at the same time if they are different.
> If the input is the same as the output
45 matches
Mail list logo
