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 is not present in IMA's keyri
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: Thiago Jung Bauermann
---
secu
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. Verif
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()
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 wou
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 +---
security/integrity/integrity.h | 6 ++
2 files ch
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
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 s
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
Signed-off-by: Thiago
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 either
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 a/security/integrity/ima/
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 fun
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
security/integrity/ima/ima_modsig.c | 181 +++
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 verify_
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 heade
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:
> arch/x86/crypto/des3_ede_glue.c:407:21: warning: symbol
> 'des3
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
Sign
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 | 1 +
2 files change
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/
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 +---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 7 ++
driver
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 deletion(-)
diff --git a/dri
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
--
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 files changed, 2057 insertion
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
b/drivers/crypto/chelsio/chtls/chtls
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(+)
create mode 100644 drivers/
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 ++
1 file changed, 58
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
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 f
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).
>
>
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: dbaf0624ff
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 the Coccinelle software.
>
> Sign
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
Pa
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
> Signed-off
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 authori
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 d
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 (2
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 do
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
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
---
drivers/ntb/hw/mscc/ntb_hw_switc
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 enco
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 Gun
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 ma
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
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: Michael Ellerman
Rev
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.
Signed-off-b
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 a
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
Acked-by: Allen Hubbe
Acked-by: Jon Mason
# Please enter the
Define Inline TLS state, connection management info.
Supporting macros definition.
Signed-off-by: Atul Gupta
---
drivers/crypto/chelsio/chtls/chtls.h| 491
drivers/crypto/chelsio/chtls/chtls_cm.h | 202 +
2 files changed, 693 insertions(+)
create
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
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
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 there
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
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
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 buildin
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
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.
> >
>
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
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
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
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
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
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.
>>
>> C
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
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
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
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
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
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
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
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
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
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
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
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
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 become
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 ass
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 ("crypto: talitos - Impleme
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. tpm_buf_init
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 type);
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
HMAC_SNOOP_NO_AFEU")
Signe
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
Home Page: http://go
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 submitted. That
> is
82 matches
Mail list logo
