Re: [PATCH] crypto: clarify licensing of OpenSSL asm code

On Tue, May 22, 2018 at 12:35:11PM -0700, Adam Langley wrote: > Several source files have been taken from OpenSSL. In some of them a > comment that "permission to use under GPL terms is granted" was > included below a contradictory license statement. In several cases, > there was no indication

Re: [PATCH 1/3] crypto: caam - fix MC firmware detection

On Wed, May 23, 2018 at 02:32:40PM +0300, Horia Geantă wrote: > Management Complex (MC) f/w detection is based on CTPR_MS[DPAA2] bit. > > This is incorrect since: > -the bit is set for all CAAM blocks integrated in SoCs with a certain > Layerscape Chassis > -some SoCs with LS Chassis don't have

Re: [PATCH v2] crypto: Mark MORUS SIMD glue as x86-specific

On Mon, May 21, 2018 at 09:41:51PM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for > MORUS") accidetally consiedered the glue code to be usable by different > architectures, but it seems to be only usable on x86. > >

Re: [PATCH 0/5] crypto: eliminate redundant decryption test vectors

On Sun, May 20, 2018 at 10:50:24PM -0700, Eric Biggers wrote: > Hello, > > When adding the Speck cipher support I was annoyed by having to add both > encryption and decryption test vectors, since they are redundant: the > decryption ones are just the encryption ones with the input and result >

[PATCH] crypto: morus - Hide Kconfig option for glue code

Enabling the glue drivers for morus640 and/or morus1280 leads to a build failure on all non-x86 architectures: crypto/morus1280_glue.c:24:10: fatal error: asm/fpu/api.h: No such file or directory scripts/Makefile.build:311: recipe for target 'crypto/morus1280_glue.o' failed

[PATCH] crypto: inside-secure - increase minimum transfer size

From: Ofer Heifetz The token size was increased for AEAD support. Occasional authentication fails arise since the result descriptor overflows. This is because the token size and the engine minimal thresholds must be in sync. Signed-off-by: Ofer Heifetz

[PATCH v2 0/5] build warnings cleanup

Build warnings cleanup reported for - using only 128b key - wait for buffer in sendmsg/sendpage - check for null before using skb - free rspq_skb_cache in error path - indentation v2: Added bug report description for 0002 Incorported comments from Dan Carpenter Atul Gupta (5):

[PATCH v2 1/5] crypto:chtls: key len correction

corrected the key length to copy 128b key. Removed 192b and 256b key as user input supports key of size 128b in gcm_ctx Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_hw.c | 6 +- 1 file changed,

[PATCH v2 5/5] crypto: chtls: free beyond end rspq_skb_cache

Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/crypto/chelsio/chtls/chtls_main.c

[PATCH v2 2/5] crypto: chtls: wait for memory sendmsg, sendpage

address suspicious code 1210 set_bit(SOCK_NOSPACE, >sk_socket->flags); 1211 } The issue is that in the code above, set_bit is never reached due to the 'continue' statement at line 1208. Also reported by bug report: 1210

[PATCH v2 3/5] crypto: chtls: dereference null variable

skb dereferenced before check in sendpage Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH v2 4/5] crypto: chtls: kbuild warnings

- unindented continue - check for null page - signed return Reported-by: Dan Carpenter Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git

Re: PBKDF2 support in the linux kernel

On Sun, May 27, 2018 at 01:22:05PM +0200, Rafael J. Wysocki wrote: > Again, the PBKDF2 user would be hibernation. It could either take a key from > user space, which would require a key-generating user-space component to be > present in the initramfs (I guess no issue for a regular distro, but I

Re: PBKDF2 support in the linux kernel

On Saturday, May 26, 2018 7:12:36 AM CEST Herbert Xu wrote: > On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote: > > Hi all, > > The request is that, we'd like to generate a symmetric key derived from > > user provided passphase(not rely on any third-party library). May I know if > > there

Re: PBKDF2 support in the linux kernel

On Sat, May 26, 2018 at 03:36:37PM +0200, Stephan Mueller wrote: > - security related code should be vetted (which arguably is the case when the > discussed PBKDF is part of the kernel) > > > > If he/she were to add their own userland code then he would surely be > > criticized for rolling his

Re: KASAN: use-after-free Read in crypto_destroy_tfm

On Sat, May 26, 2018 at 7:40 PM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0644f186fc9d Merge tag 'for_linus' of git://git.kernel.org.. > git tree: upstream > console output:

KASAN: use-after-free Read in crypto_destroy_tfm

Hello, syzbot found the following crash on: HEAD commit:0644f186fc9d Merge tag 'for_linus' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=102bc25780 kernel config: https://syzkaller.appspot.com/x/.config?x=61c12b53c2a25ec4

Re: [PATCH] crypto: x86/aegis256 - Fix wrong key buffer size

On Sun, May 20, 2018 at 10:57:23AM +0200, Ondrej Mosnáček wrote: > From: Ondrej Mosnacek > > AEGIS-256 key is two blocks, not one. > > Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations") > Reported-by: Eric Biggers >

Re: [PATCH 0/6] crypto: crc32 cleanups and unkeyed tests

On Sat, May 19, 2018 at 10:07:36PM -0700, Eric Biggers wrote: > This series fixes up alignment for crc32-generic and crc32c-generic, > removes test vectors for bfin_crc that are no longer needed, and adds > unkeyed test vectors for crc32 and an extra unkeyed test vector for > crc32c. Adding the

Re: [PATCH] crypto: chtls - fix a missing-check bug

On Fri, May 18, 2018 at 02:55:35PM -0500, Wenwen Wang wrote: > In do_chtls_setsockopt(), the tls crypto info is first copied from the > poiner 'optval' in userspace and saved to 'tmp_crypto_info'. Then the > 'version' of the crypto info is checked. If the version is not as expected, > i.e.,

Re: [PATCH] crypto: inside-secure - do not use memset on MMIO

On Thu, May 17, 2018 at 03:22:14PM +0200, Antoine Tenart wrote: > This patch fixes the Inside Secure driver which uses a memtset() call to > set an MMIO area from the cryptographic engine to 0. This is wrong as > memset() isn't guaranteed to work on MMIO for many reasons. This led to > kernel

Re: [PATCH v2 00/10] crypto: inside-secure - AEAD support

On Mon, May 14, 2018 at 03:10:54PM +0200, Antoine Tenart wrote: > This series brings AEAD algorithms to the Inside Secure SafeXcel driver. > The first 7 commits rework the driver to allow the future AEAD addition, > and then 3 commits add AEAD functions and 3 algorithms. > > This is based on top

Re: [PATCH] crypto: chtls: generic handling of data and hdr

On Mon, May 14, 2018 at 04:41:38PM +0530, Atul Gupta wrote: > removed redundant check and made TLS PDU and header recv > handling common as received from HW. > Ensure that only tls header is read in cpl_rx_tls_cmp > read-ahead and skb is freed when entire data is processed. > > Signed-off-by:

Re: PBKDF2 support in the linux kernel

Am Samstag, 26. Mai 2018, 14:17:11 CEST schrieb Jeffrey Walton: Hi Jeffrey, > On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > > >> So the problem is that Yu would

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, > >> So the problem is that Yu would like to use this for hibernation encryption >> done entirely in the kernel. > > But why do you

Re: WARNING: kernel stack regs has bad 'bp' value (3)

On Sat, May 12, 2018 at 10:43:08AM +0200, Dmitry Vyukov wrote: > On Fri, Feb 2, 2018 at 11:18 PM, Eric Biggers wrote: > > On Fri, Feb 02, 2018 at 02:57:32PM +0100, Dmitry Vyukov wrote: > >> On Fri, Feb 2, 2018 at 2:48 PM, syzbot > >>

[PATCH 1/2] crypto: x86/salsa20 - remove x86 salsa20 implementations

From: Eric Biggers The x86 assembly implementations of Salsa20 use the frame base pointer register (%ebp or %rbp), which breaks frame pointer convention and breaks stack traces when unwinding from an interrupt in the crypto code. Recent (v4.10+) kernels will warn about this,

[PATCH 2/2] crypto: salsa20 - Revert "crypto: salsa20 - export generic helpers"

From: Eric Biggers This reverts commit eb772f37ae8163a89e28a435f6a18742ae06653b, as now the x86 Salsa20 implementation has been removed and the generic helpers are no longer needed outside of salsa20_generic.c. We could keep this just in case someone else wants to add a new

[PATCH 0/2] crypto: remove x86 salsa20 implementations

Hello, The x86 asm implementations of Salsa20 have been missed so far in the fixes to stop abusing %ebp/%rbp in asm code to get correct stack traces. This has been causing the unwinder warnings reported by syzkaller to continue. This series "fixes" it by just removing the offending salsa20-asm

Re: PBKDF2 support in the linux kernel

On Tue, May 22, 2018 at 11:00:40AM +0800, Yu Chen wrote: > Hi all, > The request is that, we'd like to generate a symmetric key derived from > user provided passphase(not rely on any third-party library). May I know if > there is a PBKDF2(Password-Based Key Derivation Function 2) support in the >

[PATCHv2 1/2] crypto: ccp: Add DOWNLOAD_FIRMWARE SEV command

The DOWNLOAD_FIRMWARE command, added as of SEV API v0.15, allows the OS to install SEV firmware newer than the currently active SEV firmware. For the new SEV firmware to be applied it must: * Pass the validation test performed by the existing firmware. * Be of the same build or a newer build

[PATCHv2 2/2] crypto: ccp: Add GET_ID SEV command

The GET_ID command, added as of SEV API v0.16, allows the SEV firmware to be queried about a unique CPU ID. This unique ID can then be used to obtain the public certificate containing the Chip Endorsement Key (CEK) public key signed by the AMD SEV Signing Key (ASK). For more information please

[PATCHv2 0/2] Add new SEV commands

This patchset adds two new SEV commands, introduced in SEV API v0.15 and v0.16 respectively. * DOWNLOAD_FIRMWARE allows the SEV firmware to be updated if a blob newer than or similar to the exisiting build is available. * GET_ID allows to query for a unique ID that can be used to retrieve the

Re: PBKDF2 support in the linux kernel

Hi Denis, On Fri, May 25, 2018 at 09:48:36AM -0500, Denis Kenzior wrote: > Hi Eric, > > > The solution to the "too many system calls" problem is trivial: just do > > SHA-512 > > in userspace. It's just math; you don't need a system call, any more than > > you > > would call sys_add(1, 1) to

Re: PBKDF2 support in the linux kernel

Hi Eric, The solution to the "too many system calls" problem is trivial: just do SHA-512 in userspace. It's just math; you don't need a system call, any more than you would call sys_add(1, 1) to compute 1 + 1. The CPU instructions that can accelerate SHA-512, such as AVX and ARM CE, are

Re: PBKDF2 support in the linux kernel

On Fri, May 25, 2018 at 12:07:06PM +0200, Tomas Mraz wrote: > > Because having millions of copies of SHA1, MD5, and SHA2 and in > millions of applications is the best thing. > > Now that's something I would call laziness - just copy the code and do > not care about doing the proper decision

[bug report] crypto: chtls - Register chtls with net tls

Hello Atul Gupta, The patch a08943947873: "crypto: chtls - Register chtls with net tls" from Mar 31, 2018, leads to the following static checker warning: drivers/crypto/chelsio/chtls/chtls_main.c:352 chtls_recv_packet() error: double free of 'skb'

Re: PBKDF2 support in the linux kernel

On Thu, 2018-05-24 at 20:42 -0400, Theodore Y. Ts'o wrote: > On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote: > > > > But seriously, how is it a fault of the 'random person on the > > mailing list' > > that AF_ALG exists and is being used for its (seemingly intended) > > purpose? >

[PATCH] Add MODULE_FIRMWARE for all qat drivers

Signed-off-by: Conor McLoughlin --- drivers/crypto/qat/qat_c3xxx/adf_drv.c| 2 ++ drivers/crypto/qat/qat_c62x/adf_drv.c | 2 ++ drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 1 + 3 files changed, 5 insertions(+) diff --git

Re: PBKDF2 support in the linux kernel

Hi Denis, On Thu, May 24, 2018 at 07:56:50PM -0500, Denis Kenzior wrote: > Hi Ted, > > > > I'm not really here to criticize or judge the past. AF_ALG exists now. It > > > is being used. Can we just make it better? Or are we going to whinge at > > > every user that tries to use (and improve)

Re: PBKDF2 support in the linux kernel

Hi Ted, I'm not really here to criticize or judge the past. AF_ALG exists now. It is being used. Can we just make it better? Or are we going to whinge at every user that tries to use (and improve) kernel features that (some) people disagree with because it can 'compromise' kernel security?

Re: PBKDF2 support in the linux kernel

One more thought about why userspace using AF_ALG is a bad idea --- there is no guarantee that all kernels will have all of the crypto algorithms you need built into the kernel. People who build custom kernels very often only include those kernel modules they need. So by default I don't normally

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote: > > But seriously, how is it a fault of the 'random person on the mailing list' > that AF_ALG exists and is being used for its (seemingly intended) purpose? > > I'm not really here to criticize or judge the past. AF_ALG exists now.

Re: PBKDF2 support in the linux kernel

Hi Ted, On 05/24/2018 06:25 PM, Theodore Y. Ts'o wrote: On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote: Actually for the use case we have, speed is something pretty low on the priority list; not having to deal with userspace crypto library dependencies was a goal in and of

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote: > Actually for the use case we have, speed is something pretty low on the > priority list; not having to deal with userspace crypto library dependencies > was a goal in and of itself. Each one has its own issues and you can never >

Re: PBKDF2 support in the linux kernel

Hi Ted, On 05/24/2018 04:05 PM, Theodore Y. Ts'o wrote: Has anyone actually done the experiment and verified that it was in fact a win to use AF_ALG on at least _some_ platform? What about the common cast for most platforms, even those that had some kind of hardware accleration that could only

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 12:11:35PM -0500, Denis Kenzior wrote: > > Well, I'm not sure where the laziness comment is coming from. We have at > least two user-space implementations that implement PBKDF on top of AF_ALG. > But a typical invocation of PBKDF runs a couple of thousand iterations. >

Re: PBKDF2 support in the linux kernel

Hi Eric, No, we don't add random code to the kernel just because people are lazy. IMO it was a mistake that AF_ALG allows access to software crypto implementations by default (as opposed to just hardware crypto devices), but it's not an excuse to I understand, but my point is, AF_ALG is out

Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 09:36:15AM -0500, Denis Kenzior wrote: > Hi Stephan, > > On 05/24/2018 12:57 AM, Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: > > > > Hi Eric, > > > > > > > > "Not having to rely on any third-party library" is not an excuse

Re: PBKDF2 support in the linux kernel

Hi Stephan, On 05/24/2018 12:57 AM, Stephan Mueller wrote: Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: Hi Eric, "Not having to rely on any third-party library" is not an excuse to add random code to the kernel, which runs in a privileged context. Please do PBKDF2 in

[PATCH v2 2/5] crypto: ccree: better clock handling

Use managed clock handling, differentiate between no clock (possibly OK) and clock init failure (never OK) and correctly handle clock detection being deferred. Suggested-by: Geert Uytterhoeven Signed-off-by: Gilad Ben-Yossef ---

[PATCH v2 3/5] crypto: ccree: silence debug prints

The cache parameter register configuration was being too verbose. Use dev_dbg() to only provide the information if needed. Signed-off-by: Gilad Ben-Yossef --- drivers/crypto/ccree/cc_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v2 5/5] arm64: dts: renesas: r8a7795: add ccree binding

Add bindings for CryptoCell instance in the SoC. Signed-off-by: Gilad Ben-Yossef --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 9 + 1 file changed, 9 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi

[PATCH v2 4/5] clk: renesas: r8a7795: add ccree clock bindings

This patch adds the clock used by the CryptoCell 630p instance in the SoC. Signed-off-by: Gilad Ben-Yossef --- This patch depends upon the "clk: renesas: r8a7795: Add CR clock" patch from Geert Uytterhoeven. drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 + 1 file changed, 1

[PATCH v2 0/5] crypto: ccree: cleanup, fixes and R-Car enabling

The patch set enables the use of CryptoCell found in some Renesas R-Car Salvator-X boards and fixes some driver issues uncovered that prevented to work properly. Changes from v1: - Properly fix the bug that caused us to read a bad signature register rather than dropping the check - Proper DT

[PATCH v2 1/5] crypto: ccree: correct host regs offset

The product signature and HW revision register have different offset on the older HW revisions. This fixes the problem of the driver failing sanity check on silicon despite working on the FPGA emulation systems. Fixes: 27b3b22dd98c ("crypto: ccree - add support for older HW revs") Cc:

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Thu, May 24, 2018 at 3:20 PM, Gilad Ben-Yossef wrote: > On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven > wrote: >> On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef >> wrote: >>> On Thu, May 17, 2018 at 1:16

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Tue, May 22, 2018 at 10:48 AM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef wrote: >> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven >> wrote: >>> Indeed. From a quick glance,

[PATCH 0/3] crypto:chelsio: Fixes and cleanup

It includes Fixes and cleanup . Harsh Jain (3): crypto:chelsio:Return -ENOSPC for transient busy indication. crypt:chelsio:Send IV as Immediate for cipher algo crypto:chelsio: Remove separate buffer used for DMA map B0 block in CCM drivers/crypto/chelsio/chcr_algo.c | 303

[PATCH 1/3] crypto:chelsio:Return -ENOSPC for transient busy indication.

Change the return type based on following patch https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg28552.html Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 56 ++ 1 file changed, 26 insertions(+), 30

[PATCH 2/3] crypt:chelsio:Send IV as Immediate for cipher algo

Send IV in WR as immediate instead of dma mapped entry for cipher. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 49 +++- drivers/crypto/chelsio/chcr_algo.h | 3 +-- drivers/crypto/chelsio/chcr_core.h | 2 +-

[PATCH 3/3] crypto:chelsio: Remove separate buffer used for DMA map B0 block in CCM

Extends memory required for IV to include B0 Block and DMA map in single operation. Signed-off-by: Harsh Jain --- drivers/crypto/chelsio/chcr_algo.c | 198 --- drivers/crypto/chelsio/chcr_crypto.h | 12 +-- 2 files changed, 97 insertions(+),

Re: PBKDF2 support in the linux kernel

On Thursday, May 24, 2018 11:36:04 AM CEST Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, > > > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J.

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 11:27:56 CEST schrieb Rafael J. Wysocki: Hi Rafael, > On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > > > Hi Rafael, > > Hi Stephan, > > > > So the problem is that Yu

Re: PBKDF2 support in the linux kernel

On Thursday, May 24, 2018 11:11:32 AM CEST Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, Hi Stephan, > > So the problem is that Yu would like to use this for hibernation encryption > > done entirely in the kernel. > > But why do

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: Hi Rafael, > So the problem is that Yu would like to use this for hibernation encryption > done entirely in the kernel. But why do you need to perform PBKDF in kernel space? If you retain the password information in the

Re: PBKDF2 support in the linux kernel

On Thursday, May 24, 2018 7:57:37 AM CEST Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: > > Hi Eric, > > > > > "Not having to rely on any third-party library" is not an excuse to add > > random code to the kernel, which runs in a privileged context.

Re: PBKDF2 support in the linux kernel

Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: Hi Eric, > > "Not having to rely on any third-party library" is not an excuse to add > random code to the kernel, which runs in a privileged context. Please do > PBKDF2 in userspace instead. I second that. Besides, if you really

Re: PBKDF2 support in the linux kernel

Hi Yu, On Thu, May 24, 2018 at 10:26:12AM +0800, Yu Chen wrote: > Hi Stephan, > thanks for your reply, > On Wed, May 23, 2018 at 1:43 AM Stephan Mueller wrote: > > > Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: > > > Hi Yu, > > > > Hi all, > > > The request

Re: PBKDF2 support in the linux kernel

Hi Stephan, thanks for your reply, On Wed, May 23, 2018 at 1:43 AM Stephan Mueller wrote: > Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: > Hi Yu, > > Hi all, > > The request is that, we'd like to generate a symmetric key derived from > > user provided

[PATCH 3/3] crypto: caam/qi - fix warning in init_cgr()

Coverity warns about an "Unintentional integer overflow (OVERFLOW_BEFORE_WIDEN)" when computing the congestion threshold value. Even though it is highly unlikely for an overflow to happen, use this as an opportunity to simplify the code. Signed-off-by: Horia Geantă ---

[PATCH 1/3] crypto: caam - fix MC firmware detection

Management Complex (MC) f/w detection is based on CTPR_MS[DPAA2] bit. This is incorrect since: -the bit is set for all CAAM blocks integrated in SoCs with a certain Layerscape Chassis -some SoCs with LS Chassis don't have an MC block (thus no MC f/w) To fix this, MC f/w detection will be based

[PATCH 2/3] crypto: caam - fix rfc4543 descriptors

In some cases the CCB DMA-based internal transfer started by the MOVE command (src=M3 register, dst=descriptor buffer) does not finish in time and DECO executes the unpatched descriptor. This leads eventually to a DECO Watchdog Timer timeout error. To make sure the transfer ends, change the MOVE

[PATCH v7 02/14] PKCS#7: Refactor verify_pkcs7_signature() and add pkcs7_get_message_sig()

IMA will need to verify a PKCS#7 which has already been parsed. For this reason, factor out the code which does that from verify_pkcs7_signature() into a new function which takes a struct pkcs7_message instead of a data buffer. In addition, IMA will need to know the key that signed a given PKCS#7

[PATCH v7 06/14] integrity: Introduce asymmetric_sig_has_known_key()

IMA will only look for a modsig if the xattr sig references a key which is not in the expected kernel keyring. To that end, introduce asymmetric_sig_has_known_key(). The logic of extracting the key used in the xattr sig is factored out from asymmetric_verify() so that it can be used by the new

[PATCH v7 09/14] ima: Export func_tokens

ima_read_modsig() will need it so that it can show an error message. Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/ima.h| 2 ++ security/integrity/ima/ima_policy.c | 12 ++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH v7 07/14] integrity: Select CONFIG_KEYS instead of depending on it

This avoids a dependency cycle in soon-to-be-introduced CONFIG_IMA_APPRAISE_MODSIG: it will select CONFIG_MODULE_SIG_FORMAT which in turn selects CONFIG_KEYS. Kconfig then complains that CONFIG_INTEGRITY_SIGNATURE depends on CONFIG_KEYS. Signed-off-by: Thiago Jung Bauermann

[PATCH v7 10/14] ima: Add modsig appraise_type option for module-style appended signatures

Introduce the modsig keyword to the IMA policy syntax to specify that a given hook should expect the file to have the IMA signature appended to it. Here is how it can be used in a rule: appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig With this rule, IMA will accept either a

[PATCH v7 08/14] ima: Introduce is_signed()

With the introduction of another IMA signature type (modsig), some places will need to check for both of them. It is cleaner to do that if there's a helper function to tell whether an xattr_value represents an IMA signature. Suggested-by: Mimi Zohar Signed-off-by:

[PATCH v7 12/14] ima: Add new "d-sig" template field

Define new "d-sig" template field which holds the digest that is expected to match the one contained in the modsig. Suggested-by: Mimi Zohar Signed-off-by: Thiago Jung Bauermann --- Documentation/security/IMA-templates.rst | 5 +

[PATCH v7 14/14] ima: Store the measurement again when appraising a modsig

If the IMA template contains the 'sig' field, then the modsig should be added to the measurement list when the file is appraised, and that is what normally happens. But If a measurement rule caused a file containing a modsig to be measured before a different rule causes it to be appraised, the

[PATCH v7 11/14] ima: Implement support for module-style appended signatures

Implement the appraise_type=imasig|modsig option, allowing IMA to read and verify modsig signatures. In case both are present in the same file, IMA will first check whether the key used by the xattr signature is present in the kernel keyring. If not, it will try the appended signature.

[PATCH v7 13/14] ima: Write modsig to the measurement list

Add modsig support to the "sig" template field, allowing the the contents of the modsig to be included in the measurement list. Suggested-by: Mimi Zohar Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/ima.h | 7

[PATCH v7 05/14] integrity: Introduce integrity_keyring_from_id()

IMA will need to obtain the keyring used to verify file signatures so that it can verify the module-style signature appended to files. Signed-off-by: Thiago Jung Bauermann Signed-off-by: Mimi Zohar --- security/integrity/digsig.c| 28

[PATCH v7 03/14] PKCS#7: Introduce pkcs7_get_digest()

IMA will need to access the digest of the PKCS7 message (as calculated by the kernel) before the signature is verified, so introduce pkcs7_get_digest() for that purpose. Also, modify pkcs7_digest() to detect when the digest was already calculated so that it doesn't have to do redundant work.

[PATCH v7 00/14] Appended signatures support for IMA appraisal

Hello, The main difference in this version is the addition of the last patch, which ensures that there will always be a measurement entry containing the appended modsig if one was used to appraise the file. The patch description and comments in the code should explain in which circumstances the

[PATCH v7 04/14] integrity: Introduce struct evm_xattr

Even though struct evm_ima_xattr_data includes a fixed-size array to hold a SHA1 digest, most of the code ignores the array and uses the struct to mean "type indicator followed by data of unspecified size" and tracks the real size of what the struct represents in a separate length variable. The

[PATCH v7 01/14] MODSIGN: Export module signature definitions

IMA will use the module_signature format for append signatures, so export the relevant definitions and factor out the code which verifies that the appended signature trailer is valid. Also, create a CONFIG_MODULE_SIG_FORMAT option so that IMA can select it and be able to use validate_module_sig()

[PATCH] crypto: clarify licensing of OpenSSL asm code

Several source files have been taken from OpenSSL. In some of them a comment that "permission to use under GPL terms is granted" was included below a contradictory license statement. In several cases, there was no indication that the license of the code was compatible with the GPLv2. This change

Re: PBKDF2 support in the linux kernel

Am Dienstag, 22. Mai 2018, 05:00:40 CEST schrieb Yu Chen: Hi Yu, > Hi all, > The request is that, we'd like to generate a symmetric key derived from > user provided passphase(not rely on any third-party library). May I know if > there is a PBKDF2(Password-Based Key Derivation Function 2) support

Re: [PATCH RESEND 1/2] Add DOWNLOAD_FIRMWARE SEV command

On 5/10/2018 12:28 PM, Borislav Petkov wrote: Use a prefix for the subject pls: Subject: [PATCH RESEND 1/2] crypto: ccp: Add DOWNLOAD_FIRMWARE SEV command or Subject: [PATCH RESEND 1/2] crypto/ccp: Add DOWNLOAD_FIRMWARE SEV command or so. Okay. On Wed, May 09, 2018 at 11:18:27AM -0500,

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

Hi Gilad, On Mon, May 21, 2018 at 3:43 PM, Gilad Ben-Yossef wrote: > On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven > wrote: >> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c >> does not distinguish between the absence

PBKDF2 support in the linux kernel

Hi all, The request is that, we'd like to generate a symmetric key derived from user provided passphase(not rely on any third-party library). May I know if there is a PBKDF2(Password-Based Key Derivation Function 2) support in the kernel? (https://tools.ietf.org/html/rfc2898#5.2) We have hmac sha1

[PATCH v2] crypto: Mark MORUS SIMD glue as x86-specific

From: Ondrej Mosnacek Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for MORUS") accidetally consiedered the glue code to be usable by different architectures, but it seems to be only usable on x86. This patch moves it under arch/x86/crypto and adds

Re: [PATCH] crypto: Mark MORUS SIMD glue as x86-specific

2018-05-18 23:01 GMT+02:00 Ondrej Mosnáček : > From: Ondrej Mosnacek > > Commit 56e8e57fc3a7 ("crypto: morus - Add common SIMD glue code for > MORUS") accidetally consiedered the glue code to be usable by different > architectures, but it seems to be only

Re: [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding

On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven wrote: > > Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c > does not distinguish between the absence of the clock property, and an > actual error in getting the clock, and never considers any

[PATCH 4/5] crypto: testmgr - add extra kw(aes) encryption test vector

From: Eric Biggers One "kw(aes)" decryption test vector doesn't exactly match an encryption test vector with input and result swapped. In preparation for removing the decryption test vectors, add this test vector to the encryption test vectors, so we don't lose any test

[PATCH 3/5] crypto: testmgr - add extra ecb(tnepres) encryption test vectors

From: Eric Biggers None of the four "ecb(tnepres)" decryption test vectors exactly match an encryption test vector with input and result swapped. In preparation for removing the decryption test vectors, add these to the encryption test vectors, so we don't lose any test

[PATCH 1/5] crypto: testmgr - add extra ecb(des) encryption test vectors

From: Eric Biggers Two "ecb(des)" decryption test vectors don't exactly match any of the encryption test vectors with input and result swapped. In preparation for removing the decryption test vectors, add these to the encryption test vectors, so we don't lose any test

[PATCH 2/5] crypto: testmgr - make an cbc(des) encryption test vector chunked

From: Eric Biggers One "cbc(des)" decryption test vector doesn't exactly match an encryption test vector with input and result swapped. It's *almost* the same as one, but the decryption version is "chunked" while the encryption version is "unchunked". In preparation for

<    3   4   5   6   7   8   9   10   11   12   >