Re: export pcie_flr and remove copies of it in drivers V2

On Tue, Apr 18, 2017 at 01:36:12PM -0500, Bjorn Helgaas wrote: > On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote: > > Hi all, > > > > this exports the PCI layer pcie_flr helper, and removes various opencoded > > copies of it. > > > > Changes since V1: > > - rebase on top of the

padata & workqueue list corruption

Hello Steffen & Workqueue People, As Jason wrote about here a few weeks ago, we've been having issues with padata. After spending considerable time working to rule out the possibility that our code was doing something wrong, I've begun to debug padata and the workqueue subsystems. I've gotten

[PATCH 6/8] crypto: DH - add PKCS#3 parameter handling

DH parameters are commonly handled in PKCS#3 ASN.1 DER encoded files. The addition adds support for the parsing of such DER encoded parameter sets. After parsing, the data is added to the DH context data structure. This support allows using of parameter sets generated with the openssl dhparam

[PATCH 1/8] crypto: AF_ALG -- add DH keygen / ssgen API

Add the flags for handling DH key generation and DH shared secret generation. Signed-off-by: Stephan Mueller --- include/uapi/linux/if_alg.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h index

[PATCH 8/8] crypto: AF_ALG - add KPP support

The patch externalizes the KPP kernel crypto API to user space. This allows user space to make use of Diffie-Hellman and EC Diffie-Hellman operations. The following operations are supported: * DH parameters formatted in PKCS#3 with ALG_SET_DH_PARAMETERS setsockopt. The call returns the

[PATCH 5/8] crypto: DH - allow params and key to be set independently

Parameters are handled independently from the secret key. Therefore, this patch allows setting of the parameter independently from the secret key. Before invoking the actual crypto operation, the code must now check that the secret key and the parameters are all present. Signed-off-by: Stephan

[RFC PATCH 0/8] crypto: AF_ALG support for KPP

Hi, This is an RFC to discuss whether and how to support access to the KPP kernel crypto API (Diffie-Hellman and EC Diffie-Hellman) by user space. The patch set is only meant for discussion and not for production use. Testing is only performed for the DH part via [1]. The DH testing shows that

[PATCH 7/8] crypto: ecdh - constify key

Signed-off-by: Stephan Mueller --- include/crypto/ecdh.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/crypto/ecdh.h b/include/crypto/ecdh.h index 03a64f6..b5bb149 100644 --- a/include/crypto/ecdh.h +++ b/include/crypto/ecdh.h @@ -40,7 +40,7 @@

[PATCH 4/8] crypto: KPP - add API crypto_kpp_set_params

KPP mechanisms like DH require a parameter set to be provided by the caller. That parameter set may be provided by the crypto_kpp_set_secret function. Yet, the parameters hare handled independently from the secret key which implies that they should be able to be set independently from the key.

[PATCH 3/8] crypto: AF_ALG - eliminate code duplication

The handling function for setsockopt contains duplicated code which is cleaned up with this patch. This patch does not change the functionality. Signed-off-by: Stephan Mueller --- crypto/af_alg.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) diff

[PATCH 2/8] crypto: AF_ALG -- add DH param / ECDH curve setsockopt call

For supporting DH ciphers, user space must be able to set the DH parameters. The patch adds a new setsockopt call for setting these parameters. Similarly, the ECDH curve information can be set by user space via the newly added setsockopt call. Signed-off-by: Stephan Mueller

[PATCH 2/6] ima: Tidy up constant strings

Strictly speaking, boot_aggregate_name is a constant string, not a modifiable pointer to a constant string. Also, constify mask_tokens and func_tokens arrays. Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/ima_init.c | 2 +-

[PATCH 5/6] 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

[PATCH 3/6] ima: Simplify policy_func_show.

If the func_tokens array uses the same indices as enum ima_hooks, policy_func_show can be a lot simpler, and the func_* enum becomes unnecessary. Signed-off-by: Thiago Jung Bauermann --- security/integrity/ima/ima_policy.c | 47 ++---

[PATCH 1/6] integrity: Small code improvements

The keyid and sig_size members of struct signature_v2_hdr are in BE format, so use a type that makes this assumption explicit. Also, use beXX_to_cpu instead of __beXX_to_cpu to read them. Change integrity_kernel_read to take a void * buffer instead of char * buffer, so that callers don't have to

[PATCH 4/6] ima: Log the same audit cause whenever a file has no signature

If the file doesn't have an xattr, ima_appraise_measurement sets cause to "missing-hash" while if there's an xattr but it's a digest instead of a signature it sets cause to "IMA-signature-required". Fix it by setting cause to "IMA-signature-required" in both cases. Signed-off-by: Thiago Jung

[PATCH 6/6] ima: Support appended signatures for appraisal

This patch introduces the appended_imasig 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=appended_imasig appraise

[PATCH 0/6] Appended signatures support for IMA appraisal

On the OpenPOWER platform, secure boot and trusted boot are being implemented using IMA for taking measurements and verifying signatures. Since the kernel image on Power servers is an ELF binary, kernels are signed using the scripts/sign-file tool and thus use the same signature format as signed

[patch V2 04/24] padata: Avoid nested calls to get_online_cpus() in pcrypt_init_padata()

From: Sebastian Andrzej Siewior pcrypt_init_padata() get_online_cpus() padata_alloc_possible() padata_alloc() get_online_cpus() The nested call to get_online_cpus() works with the current implementation, but prevents the conversion to a percpu rwsem.

[patch V2 03/24] padata: Make padata_alloc() static

No users outside of padata.c Signed-off-by: Thomas Gleixner Cc: Steffen Klassert Cc: linux-crypto@vger.kernel.org --- include/linux/padata.h |3 --- kernel/padata.c| 32 2 files changed, 16

Re: export pcie_flr and remove copies of it in drivers V2

On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote: > Hi all, > > this exports the PCI layer pcie_flr helper, and removes various opencoded > copies of it. > > Changes since V1: > - rebase on top of the pci/virtualization branch > - fixed the probe case in __pci_dev_reset > -

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

El Tue, Apr 18, 2017 at 04:35:02PM +0100 Ard Biesheuvel ha dit: > On 18 April 2017 at 15:47, Paul Gortmaker > wrote: > > On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke wrote: > >> The operand is an integer constant, make the constness

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote: > > > On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > > Interesting that you didn't CC any of the maintainers. Could you > > do that in the future please? > > Please read the cover letter. The distribution list for the

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe > > Acked-by: Daniel Vetter > >

Re: [PATCH 0/4] staging: add ccree crypto driver

On Tue, Apr 18, 2017 at 06:29:22PM +0300, Gilad Ben-Yossef wrote: > On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland wrote: > > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > >>

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > Interesting that you didn't CC any of the maintainers. Could you > do that in the future please? Please read the cover letter. The distribution list for the patchset would have been way too large to cc every maintainer (even as limited as it

Re: [PATCH 0/4] staging: add ccree crypto driver

On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > accelerators. It is supported by a long lived series of out of tree > drivers, which I am now in the process of unifying and upstreaming. > This is the first

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

On 18 April 2017 at 15:47, Paul Gortmaker wrote: > On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke wrote: >> The operand is an integer constant, make the constness explicit by >> adding the modifier. This is needed for clang to generate valid

Re: [PATCH 0/4] staging: add ccree crypto driver

Hi Mark, On Tue, Apr 18, 2017 at 6:13 PM, Mark Rutland wrote: > Hi, > > On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: >> Arm TrustZone CryptoCell 700 is a family of cryptographic hardware >> accelerators. It is supported by a long lived series of out of

Re: [PATCH 0/4] staging: add ccree crypto driver

Hi, On Tue, Apr 18, 2017 at 05:07:50PM +0300, Gilad Ben-Yossef wrote: > Arm TrustZone CryptoCell 700 is a family of cryptographic hardware > accelerators. It is supported by a long lived series of out of tree > drivers, which I am now in the process of unifying and upstreaming. > This is the

Re: [PATCH v2] crypto: arm64/sha: Add constant operand modifier to ASM_EXPORT

On Wed, Apr 5, 2017 at 2:34 PM, Matthias Kaehlcke wrote: > The operand is an integer constant, make the constness explicit by > adding the modifier. This is needed for clang to generate valid code > and also works with gcc. Actually it doesn't work with all gcc. I've got an

Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote: > From: Logan Gunthorpe > > Sent: 13 April 2017 23:05 > > Straightforward conversion to the new helper, except due to > > the lack of error path, we have to warn if unmapable memory > > is ever present in the sgl. Interesting that you

RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

From: Logan Gunthorpe > Sent: 13 April 2017 23:05 > Straightforward conversion to the new helper, except due to > the lack of error path, we have to warn if unmapable memory > is ever present in the sgl. > > Signed-off-by: Logan Gunthorpe > --- >

[PATCH 0/4] staging: add ccree crypto driver

Arm TrustZone CryptoCell 700 is a family of cryptographic hardware accelerators. It is supported by a long lived series of out of tree drivers, which I am now in the process of unifying and upstreaming. This is the first drop, supporting the new CryptoCell 712 REE. The code still needs some

Re: [PATCH] padata: allow caller to control queue length

Jason A. Donenfeld wrote: > On Fri, Apr 14, 2017 at 9:57 AM, Steffen Klassert > wrote: >> Why do we need this? As long as we don't have a user that needs a >> different limit, this patch adds just some useless code. > > My [not-yet-mainlined] code

Crypto Fixes for 4.11

Hi Linus: This push fixes the following problems: - Regression in new XTS/LRW code when used with async crypto. - Long-standing bug in ahash API when used with certain algos. - Bogus memory dereference in async algif_aead with certain algos. Please pull from

Re: [RFC PATCH v1 1/1] crypto: algif_compression - User-space interface for compression

Am Donnerstag, 13. April 2017, 20:34:54 CEST schrieb Abed Kamaluddin: Hi Abed, > crypto: algif_compression - User-space interface for compression > > This patch adds af_alg plugin for compression algorithms of type scomp/acomp > registered to the kernel crypto layer. > > The user needs to set

Re: [PATCH 2/7] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver

Hi Robin, On Wed, Apr 12, 2017 at 02:54:13PM +0100, Robin Murphy wrote: > > Bit of a drive-by, but since I have it in my head that crypto drivers > are a hotspot for dodgy DMA usage (in part due to the hardware often > being a bit esoteric with embedded RAMs and such), this caught my eye > and I

Re: [PATCH 4/7] arm64: marvell: dts: add crypto engine description for 7k/8k

Hi Thomas, On Wed, Apr 12, 2017 at 10:56:08AM +0200, Thomas Petazzoni wrote: > On Wed, 29 Mar 2017 14:44:29 +0200, Antoine Tenart wrote: > > > + cpm_crypto: crypto@80 { > > + compatible = "inside-secure,safexcel-eip197"; > > +

Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: > This is a single straightforward conversion from kmap to sg_map. > > Signed-off-by: Logan Gunthorpe Acked-by: Daniel Vetter Probably makes sense to merge through some other tree,