Re: [PATCH v6 00/12] Appended signatures support for IMA appraisal

Thiago Jung Bauermann writes: > Now the modsig is only ignored if it references a signature that is not > present in IMA's keyring (or if there's a parsing error, obviously). If the The above should read "Now the modsig is only ignored if it references a *key* that

[PATCH v6 04/12] ima: Introduce is_ima_sig()

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 v6 03/12] 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 v6 00/12] Appended signatures support for IMA appraisal

Hello, The main highlight in this version is that it's not necessary to appraise the file before storing its measurement anymore. This is possible due to a new approach that Mimi suggested: we decide whether the modsig should be used or not at the time it is read from the file, while before we

[PATCH v6 01/12] 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 v6 05/12] 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 --- security/integrity/digsig.c| 28 +---

[PATCH v6 07/12] integrity: Select CONFIG_KEYS instead of depending on it

This avoids a dependency cycle in CONFIG_IMA_APPRAISE_MODSIG (introduced by a later patch in this series): 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 v6 11/12] ima: Implement support for module-style appended signatures

This patch actually implements 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

[PATCH v6 12/12] ima: Write modsig to the measurement list

Define new "d-sig" template field which holds the digest that is expected to match the one contained in the modsig. Also 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

[PATCH v6 09/12] ima: Add modsig appraise_type option for module-style appended signatures

This patch introduces 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

[PATCH v6 08/12] 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

[PATCH v6 06/12] 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 v6 10/12] ima: Add functions to read and verify a modsig signature

This is the code needed by IMA-appraise to work with modsig signatures. It will be used by the next two patches. Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/Kconfig | 3 + security/integrity/ima/ima.h| 41

[PATCH v6 02/12] PKCS#7: Introduce pkcs7_get_message_sig() and verify_pkcs7_message_sig()

IMA will need to know the key that signed a given PKCS#7 message, so add pkcs7_get_message_sig(). It will also need to verify an already parsed PKCS#7 message. For this purpose, add verify_pkcs7_message_sig() which takes a struct pkcs7_message for verification instead of the raw bytes that

[PATCH v11 crypto 00/12] Chelsio Inline TLS

Series for Chelsio Inline TLS driver (chtls) Use tls ULP infrastructure to register chtls as Inline TLS driver. Chtls use TCP Sockets to transmit and receive TLS record. TCP proto is extended to offload TLS record. T6 adapter provides the following features: -TLS record offload, TLS

Re: [PATCH][next] crypto: x86/des3_ede: make array des3_ede_skciphers static

On Mon, Mar 05, 2018 at 02:18:00PM +0100, Colin King wrote: > From: Colin Ian King > > The array des3_ede_skciphers is local to the source and does not need > to be in global scope, so make it static. > > Cleans up sparse warning: >

[PATCH v11 crypto 01/12] tls: support for Inline tls record

Facility to register Inline TLS drivers to net/tls. Setup TLS_HW_RECORD prot to listen on offload device. Cases handled - Inline TLS device exists, setup prot for TLS_HW_RECORD - Atleast one Inline TLS exists, sets TLS_HW_RECORD. - If non-inline device establish connection, move to TLS_SW_TX

[PATCH v11 crypto 02/12] ethtool: enable Inline TLS in HW

Ethtool option enables TLS record offload on HW, user configures the feature for netdev capable of Inline TLS. This allows user to define custom sk_prot for Inline TLS sock Signed-off-by: Atul Gupta --- include/linux/netdev_features.h | 2 ++ net/core/ethtool.c

[PATCH v11 crypto 03/12] cxgb4: Inline TLS FW Interface

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 +

[PATCH v11 crypto 04/12] cxgb4: LLD driver changes to support TLS

Read the Inline TLS capability from firmware. Determine the area reserved for storing the keys Dump the Inline TLS tx and rx records count. Signed-off-by: Atul Gupta --- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 32 +---

[PATCH v11 crypto 05/12] crypto: chcr - Inline TLS Key Macros

Define macro for programming the 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

[PATCH v11 crypto 07/12] crypto: chtls - Program the TLS session Key

Initialize the space reserved for storing the TLS keys, get and free the location where key is stored for the TLS connection. Program the Tx and Rx key as received from user in struct tls12_crypto_info_aes_gcm_128 and understood by hardware. added socket option TLS_RX Signed-off-by: Atul Gupta

[PATCH v11 crypto 08/12] crypto : chtls - CPL handler definition

Exchange messages with hardware to program the TLS session CPL handlers for messages received from chip. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_cm.c | 2056 +++ net/ipv4/tcp_minisocks.c|1 + 2

[PATCH v11 crypto 10/12] crypto: chtls - Inline TLS record Rx

handler for record receive. plain text copied to user buffer Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 599 1 file changed, 599 insertions(+) diff --git a/drivers/crypto/chelsio/chtls/chtls_io.c

[PATCH v11 crypto 09/12] crypto: chtls - Inline TLS record Tx

TLS handler for record transmit. Create Inline TLS work request and post to FW. Create Inline TLS record CPLs for hardware Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_io.c | 1251 +++ 1 file changed, 1251 insertions(+)

[PATCH v11 crypto 11/12] crypto: chtls - Register chtls with net tls

Register chtls as Inline TLS driver, chtls is ULD to cxgb4. Setsockopt to program (tx/rx) keys on chip. Support AES GCM of key size 128. Support both Inline Rx and Tx. Signed-off-by: Atul Gupta --- drivers/crypto/chelsio/chtls/chtls_main.c | 589

Re: [PATCH v5 00/23] crypto: arm64 - play nice with CONFIG_PREEMPT

On Sat, Mar 10, 2018 at 03:21:45PM +, Ard Biesheuvel wrote: > As reported by Sebastian, the way the arm64 NEON crypto code currently > keeps kernel mode NEON enabled across calls into skcipher_walk_xxx() is > causing problems with RT builds, given that the skcipher walk API may > allocate and

Re: [PATCH v2] crypto/ecc: Remove stack VLA usage

On Thu, Mar 08, 2018 at 01:57:02PM -0800, Kees Cook wrote: > On the quest to remove all VLAs from the kernel[1], this switches to > a pair of kmalloc regions instead of using the stack. This also moves > the get_random_bytes() after all allocations (and drops the needless > "nbytes" variable). >

Re: [PATCH] crypto: virtio - remove dependency on CRYPTO_AUTHENC

On Wed, Mar 07, 2018 at 12:53:15AM +0100, Peter Wu wrote: > virtio_crypto does not use function crypto_authenc_extractkeys, remove > this unnecessary dependency. Compiles fine and passes cryptodev-linux > cipher and speed tests from https://wiki.qemu.org/Features/VirtioCrypto > > Fixes:

Re: [PATCH] crypto: ccp: Use memdup_user() rather than duplicating its implementation

On Mon, Mar 05, 2018 at 02:10:20PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Mon, 5 Mar 2018 13:50:13 +0100 > > Reuse existing functionality from memdup_user() instead of keeping > duplicate source code. > > This issue was detected by using

Re: [PATCH v2] crypto: hash.h: Prevent use of req->result in ahash update

On Wed, Mar 07, 2018 at 11:49:33AM +0100, Kamil Konieczny wrote: > Prevent improper use of req->result field in ahash update, init, export and > import functions in drivers code. A driver should use ahash request context > if it needs to save internal state. > > Signed-off-by: Kamil Konieczny

Re: [PATCH] crypto/ccp: Validate buffer lengths for copy operations

On Wed, Mar 07, 2018 at 11:31:14AM -0600, Gary R Hook wrote: > The CCP driver copies data between scatter/gather lists and DMA buffers. > The length of the requested copy operation must be checked against > the available destination buffer length. > > Reported-by: Maciej S. Szmigiero

Re: [PATCH 0/2] crypto: introduce SM4 symmetric cipher algorithm

On Tue, Mar 06, 2018 at 09:44:41AM +, Gilad Ben-Yossef wrote: > Introduce the SM4 cipher algorithms (OSCCA GB/T 32907-2016) and > related tests. > > SM4 (GBT.32907-2016) is a cryptographic standard issued by the > Organization of State Commercial Administration of China (OSCCA) > as an

Re: [PATCH v2 0/5] crypto:chelsio: Bug fixes and cleanup

On Tue, Mar 06, 2018 at 10:37:47AM +0530, Harsh Jain wrote: > It includes bug fixes and code cleanup. > > Changes from v1: > > Remove Redundant soffset initialisation from 2/5. > > Harsh Jain (5): > crypto:chelsio: Use kernel round function to align lengths > crypto:chelsio: Fix src buffer

Re: [PATCH v2 0/2] hwrng: mxc-rnga - add driver support on boards with device tree

On Tue, Mar 06, 2018 at 12:20:58AM +0200, Vladimir Zapolskiy wrote: > The series is a trivial change to extend Freescale i.MX31 RNGA > driver to work on boards with device description taken from device > tree blob. The change was tested on a legacy LogicPD MX31Lite board. > > Vladimir Zapolskiy

Re: [RFC PATCH] crypto: arm64/speck - add NEON-accelerated implementation of Speck-XTS

On Mon, Mar 05, 2018 at 11:17:07AM -0800, Eric Biggers wrote: > Add a NEON-accelerated implementation of Speck128-XTS and Speck64-XTS > for ARM64. This is ported from the 32-bit version. It may be useful on > devices with 64-bit ARM CPUs that don't have the Cryptography > Extensions, so cannot

[PATCH v12 8/9] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64 functions in non-64bit cases in favour of the new common io-64-nonatomic-lo-hi header. To be consistent with CAAM engine HW spec: in case of 64-bit registers, irrespective of device endianness, the lower address should be read from

[PATCH v12 9/9] ntb: ntb_hw_switchtec: Cleanup 64bit IO defines to use the common header

Clean up the ifdefs which conditionally defined the io{read|write}64 functions in favour of the new common io-64-nonatomic-lo-hi header. Per a nit from Andy Shevchenko, the include list is also made alphabetical. Signed-off-by: Logan Gunthorpe Cc: Jon Mason

[PATCH v12 2/9] parisc: iomap: introduce io{read|write}64

Add support for io{read|write}64() functions in parisc architecture. These are pretty straightforward copies of similar functions which make use of readq and writeq. Also, indicate that the lo_hi and hi_lo variants of these functions are not provided by this architecture. Signed-off-by: Logan

[PATCH v12 1/9] iomap: Fix sparse endian check warnings

Warnings of the form: lib/iomap.c:84:9: warning: cast to restricted __be16 Are found when running sparse checker with: make C=2 CF=-D__CHECK_ENDIAN__ This patch casts them with __force to suppress the warnings. Also, it looks like the wrong conversion function was used in the mmio_writeXXbe

[PATCH v12 6/9] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if they are not already defined by the architecture. (As they are provided by the generic iomap library). The patch also points io{read|write}64[be] to the variant specified by the header name. This is because new drivers are

[PATCH v12 0/9] Add io{read|write}64 to io-64-atomic headers

This is v12 of my cleanup series to push a number of instances of people defining their own io{read|write}64 functions into common headers seing they don't exist in non-64bit systems. This series adds inline functions to the io-64-nonatomic headers and then cleans up the drivers that defined their

[PATCH v12 3/9] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-by:

[PATCH v12 4/9] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions.

[PATCH v12 5/9] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

In order to provide non-atomic functions for io{read|write}64 that will use readq and writeq when appropriate. We define a number of variants of these functions in the generic iomap that will do non-atomic operations on pio but atomic operations on mmio. These functions are only defined if readq

[PATCH v12 7/9] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

Now that ioread64 and iowrite64 are available in io-64-nonatomic, we can remove the hack at the top of ntb_hw_intel.c and replace it with an include. Signed-off-by: Logan Gunthorpe Reviewed-by: Andy Shevchenko Acked-by: Dave Jiang

[PATCH v2 04/21] fbdev: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 01/21] ASoC: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

Re: [PATCH] crypto: doc - clarify hash callbacks state machine

On Mon, Mar 05, 2018 at 12:39:45PM +0200, Horia Geantă wrote: > Even though it doesn't make too much sense, it is perfectly legal to: > - call .init() and then (as many times) .update() > - subseqently _not_ call any of .final(), .finup() or .export() Actually it makes perfect sense, because

[PATCH v2 16/21] remoteproc: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 03/21] crypto: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 00/21] Allow compile-testing NO_DMA (drivers)

Hi all, If NO_DMA=y, get_dma_ops() returns a reference to the non-existing symbol bad_dma_ops, thus causing a link failure if it is ever used. The intention of this is twofold: 1. To catch users of the DMA API on systems that do no support the DMA mapping API, 2. To avoid

[PATCH v2 10/21] lightnvm: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

Re: [PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

On Thu, Jan 18, 2018 at 04:44:21PM -0800, Megha Dey wrote: > > > So the mcryptd template is in fact completely superfluous. You > > can remove it and just have all the main encrypt/decrypt functions > > invoke the underlying encrypt/decrypt function directly and achieve > > the same result. > >

[PATCH v2 08/21] iio: adc: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 07/21] i2c: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

Re: [PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency

On 16/03/2018 13:51, Geert Uytterhoeven wrote: Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and

[PATCH v2 09/21] iommu: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 13/21] mmc: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

Re: [PATCH] crypto: talitos - fix IPsec cipher in length

On 3/16/2018 2:42 PM, Christophe LEROY wrote: > Le 16/03/2018 à 09:48, Horia Geantă a écrit : >> For SEC 2.x+, cipher in length must contain only the ciphertext length. >> In case of using hardware ICV checking, the ICV length is provided via >> the "extent" field of the descriptor pointer. >> >>

[PATCH v2 05/21] firewire: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 19/21] spi: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 06/21] fpga: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 20/21] staging: vc04_services: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 14/21] mtd: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 11/21] mailbox: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 17/21] scsi: hisi_sas: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 15/21] net: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

[PATCH v2 18/21] serial: Remove depends on HAS_DMA in case of platform dependency

Remove dependencies on HAS_DMA where a Kconfig symbol depends on another symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST". In most cases this other symbol is an architecture or platform specific symbol, or PCI. Generic symbols and drivers without platform dependencies keep their

Re: [PATCH v3 0/6] add integrity and security to TPM2 transactions

On Mon, Mar 12, 2018 at 08:57:13AM -0700, James Bottomley wrote: > I think the way I'm going to fix the trusted key policy problem is to > move it back into the kernel for the simple PCR lock policy (which will > make changing from 1.2 to 2.0 seamless because the external Key API > will then

[bug report] crypto: omap-aes - Add support for GCM mode

Hello Tero Kristo, This is a semi-automatic email about new static checker warnings. The patch ad18cc9d0f91: "crypto: omap-aes - Add support for GCM mode" from May 24, 2017, leads to the following Smatch complaint: drivers/crypto/omap-aes.c:1262 omap_aes_probe() error: we previously

Re: [PATCH] crypto: talitos - fix IPsec cipher in length

Le 16/03/2018 à 09:48, Horia Geantă a écrit : For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the "extent" field of the descriptor pointer. Cc: # 4.8+ Fixes: 549bd8bc5987

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

On Fri, 2018-03-16 at 13:58 +0200, Jarkko Sakkinen wrote: > On Sat, 2018-03-10 at 14:14 -0800, James Bottomley wrote: > > TPM_BUF_OVERFLOW= BIT(0), > > + TPM_BUF_2B = BIT(1), > > Instead of re-using this I would prefer to have another enum for > buffer type.

Re: [PATCH v3 1/6] tpm-buf: create new functions for handling TPM buffers

On Sat, 2018-03-10 at 14:14 -0800, James Bottomley wrote: > TPM_BUF_OVERFLOW= BIT(0), > + TPM_BUF_2B = BIT(1), Instead of re-using this I would prefer to have another enum for buffer type. tpm_buf_init() could have the signature: int tpm_buf_init(unsigned int

[PATCH] crypto: talitos - fix IPsec cipher in length

For SEC 2.x+, cipher in length must contain only the ciphertext length. In case of using hardware ICV checking, the ICV length is provided via the "extent" field of the descriptor pointer. Cc: # 4.8+ Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using

Re: [PATCH 00/12] crypto: inside-secure - hmac(sha256/sha224) support

On Thu, Mar 15, 2018 at 04:45:54PM +0100, Antoine Tenart wrote: > > I made a small mistake as the first 3 patches of the series already > were merged into your tree, as they already were sent in a previous > series. You can just ignore them. OK. Thanks, -- Email: Herbert Xu

Re: [RFC PATCH] crypto: pcrypt - forbid recursive instantiation

On Sat, Mar 10, 2018 at 03:22:31PM -0800, Eric Biggers wrote: > From: Eric Biggers > > If the pcrypt template is used multiple times in an algorithm, then a > deadlock occurs because all pcrypt instances share the same > padata_instance, which completes requests in the order