On Wed, Aug 21, 2019 at 09:13:36AM +0200, Milan Broz wrote:
>
> NACK.
>
> The whole principle of dm-crypt target is that it NEVER EVER submits
> plaintext data down the stack in bio.
>
> If you want to do some lower/higher layer encryption, use key management
> on a different layer.
> So here, j
On Wed, Aug 21, 2019 at 09:35:36AM +0200, Herbert Xu Herbert wrote:
> I agree. Please take a look at the recent ESSIV patches on
> linux-crypto and build multi-block operations on top of them
> which can then be implemented by the hardware.
>
> Cheers,
Can you tell me which patch you mentioned?
On Wed, Aug 21, 2019 at 04:57:41PM +0900, boojin.kim wrote:
>
> Can you tell me which patch you mentioned? Is this?
> https://patches.linaro.org/project/linux-crypto/list/?series=22762
Yes this is the one.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: htt
On 8/21/19 12:42 AM, boojin.kim wrote:
> This patch supports crypto information to be maintained via BIO
> and passed to the storage driver.
>
> To do this, 'bi_aux_private', 'REQ_CYPTE' and 'bi_dun' are added
> to the block layer.
>
> 'bi_aux_private' is added for loading additional private info
On 8/21/19 21:09 AM, Jens Axboe wrote:
> This isn't going to happen. With this, and the inline encryption
> proposed by Google, we'll bloat the bio even more. At least the Google
> approach didn't include bio iter changes as well.
> Please work it out between yourselves so we can have a single, cl
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of
> Josh Boyer
> Sent: Tuesday, August 20, 2019 3:10 PM
> To: Pascal Van Leeuwen
> Cc: Pascal van Leeuwen ; Linux Firmware
> ;
> linux-crypto@vger.kernel.org
> Subject: Re: [GIT PULL] inside-secure: add new GPL
The following changes since commit 07b925b450bfb4cf3e141c612ec5b104658cd020:
Install only listed firmware files (2019-08-15 07:46:53 -0400)
are available in the git repository at:
https://github.com/pvanleeuwen/linux-firmware-clean.git is_driver_fw2
for you to fetch changes up to 728c53fbdd
This patch-set does restructuring of trusted keys code to create and
consolidate trusted keys subsystem.
Changes in v5:
1. Drop 5/5 patch as its more relavant along with TEE patch-set.
2. Add Reviewed-by tag for patch #2.
3. Fix build failure when "CONFIG_HEADER_TEST" and
"CONFIG_KERNEL_HEADER_
Move tpm_buf code to common include/linux/tpm.h header so that it can
be reused via other subsystems like trusted keys etc.
Also rename trusted keys TPM 1.x buffer implementation to tpm1_buf to
avoid any compilation errors.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Sumit Garg
---
drivers/ch
Move existing code to trusted keys subsystem. Also, rename files with
"tpm" as suffix which provides the underlying implementation.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Sumit Garg
---
crypto/asymmetric_keys/asym_tpm.c| 2 +-
include/Kbuild
Move TPM2 trusted keys code to trusted keys subsystem. The reason
being it's better to consolidate all the trusted keys code to a single
location so that it can be maintained sanely.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Sumit Garg
---
drivers/char/tpm/tpm-chip.c | 1 +
d
Utilize common heap based tpm_buf code for TPM1.x trusted keys rather
than using stack based tpm1_buf code. Also, remove tpm1_buf code.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Sumit Garg
Reviewed-by: Jarkko Sakkinen
---
include/keys/trusted.h | 37 +--
security/keys/trust
The AES round keys are arrays of u32s in native endianness now, so
update the function prototypes accordingly.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-core.S | 18 -
arch/arm/crypto/aes-ce-glue.c | 40 ++--
2 files changed, 29 insertions(+), 29 deletions(
Replace the vector load from memory sequence with a simple instruction
sequence to compose the tweak vector directly.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-neonbs-core.S | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/crypto/aes-neonbs-co
When the ARM AES instruction based crypto driver was introduced, there
were no known implementations that could benefit from a 4-way interleave,
and so a 3-way interleave was used instead. Since we have sufficient
space in the SIMD register file, let's switch to a 4-way interleave to
align with the
After starting a skcipher walk, the only way to ensure that all
resources it has tied up are released is to complete it. In some
cases, it will be useful to be able to abort a walk cleanly after
it has started, so add this ability to the skcipher walk API.
Signed-off-by: Ard Biesheuvel
---
crypt
Since the CTS-CBC code completes synchronously, there is no point in
keeping part of the scratch data it uses in the request context, so
move it to the stack instead.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 61 +---
1 file changed, 26 insertions(+), 35 de
Replace the vector load from memory sequence with a simple instruction
sequence to compose the tweak vector directly.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-neonbs-core.S | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/crypto/aes-neonbs-core.S
Optimize away one of the tbl instructions in the decryption path,
which turns out to be unnecessary.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-modes.S | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-mode
Replace the vector load from memory sequence with a simple instruction
sequence to compose the tweak vector directly.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-core.S | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-core.S b/arch/
Update the AES-XTS implementation based on NEON instructions so that it
can deal with inputs whose size is not a multiple of the cipher block
size. This is part of the original XTS specification, but was never
implemented before in the Linux kernel.
Since the bit slicing driver is only faster if i
Reduce the scope of the kernel_neon_begin/end regions so that the SIMD
unit is released (and thus preemption re-enabled) if the crypto operation
cannot be completed in a single scatterwalk step. This avoids scheduling
blackouts due to preemption being enabled for unbounded periods, resulting
in a m
This is a collection of improvements for the ARM and arm64 implementations
of the AES based skciphers.
NOTES:
- the last two patches add XTS ciphertext stealing test vectors and should
NOT be merged until all AES-XTS implementations have been confirmed to work
- this series applies onto v13 of m
The pure NEON AES implementation predates the bit-slicing one, and is
generally slower, unless the algorithm in question can only execute
sequentially.
So advertising the skciphers that the bit-slicing driver implements as
well serves no real purpose, and we can just disable them. Note that the
bi
Update the AES-XTS implementation based on AES instructions so that it
can deal with inputs whose size is not a multiple of the cipher block
size. This is part of the original XTS specification, but was never
implemented before in the Linux kernel.
Signed-off-by: Ard Biesheuvel
---
arch/arm/cryp
Instead of relying on the CTS template to wrap the accelerated CBC
skcipher, implement the ciphertext stealing part directly.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-core.S | 85 +
arch/arm/crypto/aes-ce-glue.c | 188 ++--
2 files changed, 256 insertions
Add the missing support for ciphertext stealing in the implementation
of AES-XTS, which is part of the XTS specification but was omitted up
until now due to lack of a need for it.
The asm helpers are updated so they can deal with any input size, as
long as the last full block and the final partial
Update the AES-XTS implementation based on NEON instructions so that it
can deal with inputs whose size is not a multiple of the cipher block
size. This is part of the original XTS specification, but was never
implemented before in the Linux kernel.
Signed-off-by: Ard Biesheuvel
---
arch/arm/cry
From: Pascal van Leeuwen
This patch adds test vectors for AES-XTS that cover data inputs that are
not a multiple of 16 bytes and therefore require cipher text stealing
(CTS) to be applied. Vectors were added to cover all possible alignments
combined with various interesting (i.e. for vector imple
Import the AES-XTS test vectors from IEEE publication P1619/D16
that exercise the ciphertext stealing part of the XTS algorithm,
which we haven't supported in the Linux kernel implementation up
till now.
Tested-by: Pascal van Leeuwen
Signed-off-by: Ard Biesheuvel
---
crypto/testmgr.h | 60 +
On Mon, 5 Aug 2019 15:02:15 +0200, Fabien Parent wrote:
> This commit adds the device-tree documentation for the RNG IP on the
> MediaTek MT8516 SoC.
>
> Signed-off-by: Fabien Parent
> ---
> Documentation/devicetree/bindings/rng/mtk-rng.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, t
On Tue, Aug 20, 2019 at 11:16:46AM +0530, Sumit Garg wrote:
> I agree here that 5/5 should go along with TEE patch-set. But if you
> look at initial v1 patch-set, the idea was to get feedback on trusted
> keys abstraction as a standalone patch along with testing using a TPM
> (1.x or 2.0).
>
> Sin
On Tue, Aug 20, 2019 at 11:22:05AM +0530, Sumit Garg wrote:
> On Mon, 19 Aug 2019 at 22:26, Jarkko Sakkinen
> wrote:
> >
> > On Tue, Aug 13, 2019 at 01:23:00PM +0530, Sumit Garg wrote:
> > > Move tpm_buf code to common include/linux/tpm.h header so that it can
> > > be reused via other subsystems
On Wed, Aug 21, 2019 at 06:29:01PM +0530, Sumit Garg wrote:
> [SNIP]
Thank you. And as I promised I will give my remarks about 5/5 in the
previous revision.
/Jarkko
On Fri, Aug 09, 2019 at 05:06:03PM -0400, Daniel Jordan wrote:
>
> diff --git a/kernel/padata.c b/kernel/padata.c
> index d056276a96ce..01460ea1d160 100644
> --- a/kernel/padata.c
> +++ b/kernel/padata.c
> @@ -702,10 +702,7 @@ static int __padata_remove_cpu(struct padata_instance
> *pinst, int cpu
On Mon, Aug 12, 2019 at 05:02:00PM -0400, Daniel Jordan wrote:
> __padata_remove_cpu clears the offlined CPU from the usable masks after
> padata_alloc_pd has initialized pd->cpu, which means pd->cpu could be
> initialized to this CPU, causing padata to wait indefinitely for the
> next job in padat
On Mon, Aug 12, 2019 at 08:52:23PM -0400, Daniel Jordan wrote:
>
> @@ -191,22 +184,25 @@ static struct padata_priv *padata_get_next(struct
> parallel_data *pd)
> padata = list_entry(reorder->list.next,
> struct padata_priv, list);
>
> -
On Mon, Aug 19, 2019 at 10:23:27PM +, Hook, Gary wrote:
> From: Gary R Hook
>
> If a CCP is unconfigured (e.g. there are no available queues) then
> there will be no data structures allocated for the device. Thus, we
> must check for validity of a pointer before trying to access structure
> m
On Mon, Aug 12, 2019 at 12:32:57PM -0700, Nathan Chancellor wrote:
> Clang errors out when building this macro:
>
> lib/mpi/generic_mpih-mul1.c:37:24: error: invalid use of a cast in a
> inline asm context requiring an l-value: remove the cast or build with
> -fheinous-gnu-extensions
>
On Mon, Aug 19, 2019 at 08:02:45AM -0700, Stephen Boyd wrote:
> The kthread calling this function is freezable after commit 03a3bb7ae631
> ("hwrng: core - Freeze khwrng thread during suspend") is applied.
> Unfortunately, this function uses wait_event_interruptible() but doesn't
> check for the kth
On Tue, Aug 13, 2019 at 09:06:10AM +0300, Denis Efremov wrote:
> Fix typo in nx_debugfs.c filepath. File extension changed from .h to .c
> The file nx_debugfs.h never existed.
>
> Cc: Breno Leitão
> Cc: Nayna Jain
> Cc: Paulo Flabiano Smorigo
> Cc: Dan Streetman
> Cc: Herbert Xu
> Cc: linux-c
On Fri, Aug 16, 2019 at 03:21:50PM +0300, Ard Biesheuvel wrote:
> Align the x86 code with the generic XTS template, which now supports
> ciphertext stealing as described by the IEEE XTS-AES spec P1619.
>
> Tested-by: Stephan Mueller
> Signed-off-by: Ard Biesheuvel
> ---
> v2: - move 'decrypt' fl
On Thu, Aug 15, 2019 at 12:00:42PM +0300, Ard Biesheuvel wrote:
> In my effort to remove crypto_alloc_cipher() invocations from non-crypto
> code, i ran into a DES call in the CIFS driver. This is addressed in
> patch #30.
>
> The other patches are cleanups for the quirky DES interface, and lots
>
On Sat, Aug 17, 2019 at 04:24:28PM +0200, Hans de Goede wrote:
> Hi All,
>
> Here is v2 of my patch series refactoring the current 2 separate SHA256
> C implementations into 1 and put it into a separate library.
>
> There are 3 reasons for this:
>
> 1) Remove the code duplication of having 2 sep
On Fri, Aug 16, 2019 at 03:35:45PM +0300, Ard Biesheuvel wrote:
> For correctness and compliance with the XTS-AES specification, we are
> adding support for ciphertext stealing to XTS implementations, even
> though no use cases are known that will be enabled by this.
>
> Since the s390 implementat
On Fri, Aug 16, 2019 at 05:06:24PM +0300, Ard Biesheuvel wrote:
> For correctness and compliance with the XTS-AES specification, we are
> adding support for ciphertext stealing to XTS implementations, even
> though no use cases are known that will be enabled by this.
>
> Since the Power8 implement
46 matches
Mail list logo
