On 08/04/2020 12:21, Andreas Kinzler wrote:
> Hello devs,
>
> please see issue:
> https://github.com/virtio-win/kvm-guest-drivers-windows/issues/446
>
> Short summary: When using encrypted disks with qemu (using dm-crypt) and
> pass that through LIO/vhost to qemu (via virtio-scsi) the following
On 08/04/2020 12:19, Tushar Sugandhi wrote:
> The goals of the kernel integrity subsystem are to detect if files have
> been accidentally or maliciously altered, both remotely and locally,
> appraise a file's measurement against a "good" value stored as an
> extended attribute, and enforce local fi
This patch adds decription of the allow_discard option
added in commit 84597a44a9d86ac949900441cea7da0af0f2f473.
Signed-off-by: Milan Broz
---
.../admin-guide/device-mapper/dm-integrity.rst| 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/Documentation
On 21/04/2020 20:27, Mike Snitzer wrote:
> On Mon, Apr 20 2020 at 9:46P -0400,
> Dmitry Baryshkov wrote:
>
>> From: Dmitry Baryshkov
>>
>> Allow one to use encrypted in addition to user and login key types for
>> device encryption.
>>
>> Signed-off-by: Dmitry Baryshkov
>
> I fixed up some iss
On 22/04/2020 23:40, Mike Snitzer wrote:
> On Wed, Apr 22 2020 at 12:47pm -0400,
> Milan Broz wrote:
>
>> On 21/04/2020 20:27, Mike Snitzer wrote:
>>> On Mon, Apr 20 2020 at 9:46P -0400,
>>> Dmitry Baryshkov wrote:
>>>
>>>> From: Dmi
On 23/04/2020 16:06, Mike Snitzer wrote:
>
> Seems you didn't look at the fixed patch, here is what I ultimately
> staged yesterday:
> https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.8&id=a2b35bd064baf1f4e7504c23d493a3e149172dd1
>
> dm-crypt doesn't have
On 18/06/2020 19:09, Mike Snitzer wrote:
> On Thu, Jun 18 2020 at 12:50pm -0400,
> Sami Tolvanen wrote:
>
>> On Thu, Jun 18, 2020 at 11:44:45AM -0400, Mike Snitzer wrote:
>>> I do not accept that panicing the system because of verity failure is
>>> reasonable.
>>>
>>> In fact, even rebooting (via
increase, if the patch is accepted.
But please include these version changes with every new feature.
Actually I am tracking it here for dm-verity as part of veritysetup userspace
documentation:
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMVerity
Thanks,
Milan
> On 22/06/2020 16:
Patch 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 introduced new
dm-crypt no_read_workqueue and no_write_workqueue flags.
This patch adds documentation to admin guide for them.
Signed-off-by: Milan Broz
---
Documentation/admin-guide/device-mapper/dm-crypt.rst | 6 ++
1 file changed, 6
Commit 27f5411a718c431c20007e3a2fbba6589942d04f introduced
support for encrypted keyring type.
This patch fixes documentation in admin guide to mention this type.
Signed-off-by: Milan Broz
---
Documentation/admin-guide/device-mapper/dm-crypt.rst | 2 +-
1 file changed, 1 insertion(+), 1
On 24/08/2020 03:15, Damien Le Moal wrote:
> On 2020/08/21 2:46, Milan Broz wrote:
>> Patch 39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877 introduced new
>> dm-crypt no_read_workqueue and no_write_workqueue flags.
>>
>> This patch adds documentation to admin guide for them.
On 28/08/2020 22:27, Tushar Sugandhi wrote:
> Currently, dm-crypt does not take advantage of IMA measuring
> capabilities, and ultimately the benefits of remote attestation.
>
> Measure various dm-crypt constructs by calling various device-mapper
> functions - dm_ima_*() that use IMA measuring cap
On 11/09/2020 18:30, Ard Biesheuvel wrote:
> (cc Milan and dm-devel)
>
> On Fri, 11 Sep 2020 at 19:24, Van Leeuwen, Pascal
> wrote:
>>
>>> -Original Message-
>>> From: linux-crypto-ow...@vger.kernel.org
>>> On Behalf Of Ard Biesheuvel
>>> Sent: Friday, September 11, 2020 4:11 PM
>>> To:
On 24/09/2020 07:14, Eric Biggers wrote:
> On Wed, Sep 23, 2020 at 09:27:32PM -0400, Mike Snitzer wrote:
>> You've clearly done a nice job with these changes. Looks clean.
>>
>> BUT, I'm struggling to just accept that dm-crypt needs to go to these
>> extra lengths purely because of one bad apple u
On 16/10/2020 10:49, Mickaël SalaÌn wrote:
On 16/10/2020 10:29, Mickaël SalaÌn wrote:
On 15/10/2020 18:52, Mike Snitzer wrote:
Can you please explain why you've decided to make this a Kconfig CONFIG
knob? Why not either add: a dm-verity table argument? A dm-verity
kernel module parameter?
On 26/10/2020 18:52, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
>> Replace the explicit EBOIV handling in the dm-crypt driver with calls
>> into the crypto API, which now possesses the capability to perform
>> this processing within the crypto subsystem.
On 26/10/2020 19:39, Eric Biggers wrote:
> On Mon, Oct 26, 2020 at 07:29:57PM +0100, Milan Broz wrote:
>> On 26/10/2020 18:52, Eric Biggers wrote:
>>> On Mon, Oct 26, 2020 at 03:04:46PM +0200, Gilad Ben-Yossef wrote:
>>>> Replace the explicit EBOIV handling in
On 27/10/2020 07:59, Gilad Ben-Yossef wrote:
> On Mon, Oct 26, 2020 at 9:04 PM Milan Broz wrote:
...
>> We had all of disk-IV inside dmcrypt before - but once it is partially moved
>> into crypto API
>> (ESSIV, EBOIV for now), it becomes much more complicated for user to sel
On 29/10/2020 11:05, Gilad Ben-Yossef wrote:
>
> +config CRYPTO_EBOIV
> + tristate "EBOIV support for block encryption"
> + default DM_CRYPT
> + select CRYPTO_CBC
> + help
> + Encrypted byte-offset initialization vector (EBOIV) is an IV
> + generation method that is us
Hi Mike,
since 5.0-rc4 we are not able to use LUKS2 devices with 4k sector size.
For example,
# cryptsetup luksFormat --type luks2 -c aes-xts-plain64 --integrity hmac-sha256
/dev/sdc --sector-size 4096
fails with these syslog errors:
device-mapper: crypt: Integrity AEAD, tag size 32, IV size
On 05/02/2019 23:18, Mike Snitzer wrote:
> On Tue, Feb 05 2019 at 12:06pm -0500,
> Milan Broz wrote:
>
>> Hi Mike,
>>
>> since 5.0-rc4 we are not able to use LUKS2 devices with 4k sector size.
>>
>> For example,
>> # cryptsetup luksFormat --type
stopped trimming the bio.
>
> Signed-off-by: Mikulas Patocka
> Reported-by: Milan Broz
>
> ---
> drivers/md/dm-crypt.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/drivers/md/dm-crypt.c
> ==
Hi,
from the full log it seems that it is stuck in tgtd (iSCSI).
Anyway, this is device-mapper, dm-devel is better list here.
(added to cc + Mikulas)
m.
On 3/7/19 4:26 PM, Victor Helmholtz wrote:
> Hi
>
> I have recently had a problem with my server: all writes to RAID drives were
> frozen an
syslog,
because we are moving hotzone across the whole device.)
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 36dfa36505ed..af017d044dc0 100644
--- a/drivers/md
This message should better identify the device with the integrity failure.
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 7f6462f74ac8..36dfa36505ed 100644
--- a
On 20/05/2019 16:53, Andrea Gelmini wrote:
...
> Also, changing crypttab:
> root@glet:~# cat /etc/crypttab
> sda6_crypt UUID=fe03e2e6-b8b1-4672-8a3e-b536ac4e1539 none luks,discard
>
> removing discard didn't solve the issue.
This is very strange, disabling discard should reject every discard IO
o
On 20/05/2019 23:54, Jaskaran Khurana wrote:
> Adds in-kernel pkcs7 signature checking for the roothash of
> the dm-verity hash tree.
>
> The verification is to support cases where the roothash is not secured by
> Trusted Boot, UEFI Secureboot or similar technologies.
> One of the use cases for th
every superblock write.
Signed-off-by: Milan Broz
---
drivers/md/dm-integrity.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 44e76cda087a..a2ab6a32b174 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm
On 08/06/2019 00:31, Jaskaran Khurana wrote:
> This patch set adds in-kernel pkcs7 signature checking for the roothash of
> the dm-verity hash tree.
> The verification is to support cases where the roothash is not secured by
> Trusted Boot, UEFI Secureboot or similar technologies.
...
> drivers/m
On 08/06/2019 00:31, Jaskaran Khurana wrote:
> The verification is to support cases where the roothash is not secured by
> Trusted Boot, UEFI Secureboot or similar technologies.
> One of the use cases for this is for dm-verity volumes mounted after boot,
> the root hash provided during the creation
On 14/06/2019 10:34, Ard Biesheuvel wrote:
> This series is presented as an RFC for a couple of reasons:
> - it is only build tested
> - it is unclear whether this is the right way to move away from the use of
> bare ciphers in non-crypto code
> - we haven't really discussed whether moving away f
On 17/06/2019 11:15, Ard Biesheuvel wrote:
>> I will also add that going the skcipher route rather than shash will
>> allow hardware tfm providers like CryptoCell that can do the ESSIV
>> part in hardware implement that as a single API call and/or hardware
>> invocation flow.
>> For those system th
On 13/06/2019 03:06, Jaskaran Khurana wrote:
...
> Adds DM_VERITY_VERIFY_ROOTHASH_SIG_FORCE: roothash signature *must* be
> specified for all dm verity volumes and verification must succeed prior
> to creation of device mapper block device.
I had a quick discussion about this and one suggestion w
On 17/06/2019 15:59, Ard Biesheuvel wrote:
>
> So my main question/showstopper at the moment is: which modes do we
> need to support for ESSIV? Only CBC? Any skcipher? Or both skciphers
> and AEADs?
Support, or cover by internal test? I think you nee to support everything
what dmcrypt currently a
On 17/06/2019 16:39, Ard Biesheuvel wrote:
>>
>> In other words, if you add some additional limit, we are breaking backward
>> compatibility.
>> (Despite the configuration is "wrong" from the security point of view.)
>>
>
> Yes, but breaking backward compatibility only happens if you break
> some
On 17/06/2019 19:29, Ard Biesheuvel wrote:
> On Mon, 17 Jun 2019 at 19:05, Milan Broz wrote:
>>
>> On 17/06/2019 16:39, Ard Biesheuvel wrote:
>>>>
>>>> In other words, if you add some additional limit, we are breaking backward
>>>> compatibili
On 18/06/2019 23:27, Ard Biesheuvel wrote:
> This series creates an ESSIV template that produces a skcipher or AEAD
> transform based on a tuple of the form ',,'
> (or ',,' for the AEAD case). It exposes the
> encapsulated sync or async skcipher/aead by passing through all operations,
> while using
On 19/06/2019 11:14, Ard Biesheuvel wrote:
> Apologies, this was a rebase error on my part.
>
> Could you please apply the hunk below and try again?
>
> diff --git a/crypto/essiv.c b/crypto/essiv.c
> index 029a65afb4d7..5dc2e592077e 100644
> --- a/crypto/essiv.c
> +++ b/crypto/essiv.c
> @@ -243,6
On 19/06/2019 13:16, Ard Biesheuvel wrote:
>> Try
>> cryptsetup open --type plain -c null /dev/sdd test -q
>> or
>> dmsetup create test --table " 0 417792 crypt cipher_null-ecb - 0 /dev/sdd
>> 0"
>>
>> (or just run full cryptsetup testsuite)
>>
>
> Is that your mode-test script?
>
> I saw so
On 19/06/2019 14:49, Ard Biesheuvel wrote:
> On Wed, 19 Jun 2019 at 14:36, Ard Biesheuvel
> wrote:
>>
>> On Wed, 19 Jun 2019 at 13:33, Milan Broz wrote:
>>>
>>> On 19/06/2019 13:16, Ard Biesheuvel wrote:
>>>>> Try
>>>>>
The dm-verity already uses DMERR_LIMIT on other places, so it
should also limit repeated data block corruption messages.
Signed-off-by: Milan Broz
---
drivers/md/dm-verity-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm
On 19/06/2019 18:29, Ard Biesheuvel wrote:
> This series creates an ESSIV template that produces a skcipher or AEAD
> transform based on a tuple of the form ',,'
> (or ',,' for the AEAD case). It exposes the
> encapsulated sync or async skcipher/aead by passing through all operations,
> while using
On 20/06/2019 00:37, Eric Biggers wrote:
> On Wed, Jun 19, 2019 at 06:29:21PM +0200, Ard Biesheuvel wrote:
>> Add an accelerated version of the 'essiv(cbc(aes),aes,sha256)'
>> skcipher, which is used by fscrypt, and in some cases, by dm-crypt.
>> This avoids a separate call into the AES cipher fo
On 20/06/2019 13:54, Ard Biesheuvel wrote:
> On Thu, 20 Jun 2019 at 13:22, Milan Broz wrote:
>>
>> On 19/06/2019 18:29, Ard Biesheuvel wrote:
>>> This series creates an ESSIV template that produces a skcipher or AEAD
>>> transform based on a tuple of the form &#
On 20/06/2019 14:09, Milan Broz wrote:
> On 20/06/2019 13:54, Ard Biesheuvel wrote:
>> On Thu, 20 Jun 2019 at 13:22, Milan Broz wrote:
>>>
>>> On 19/06/2019 18:29, Ard Biesheuvel wrote:
>>>> This series creates an ESSIV template that produces a skcipher or
On 20/06/2019 15:40, Herbert Xu wrote:
> On Thu, Jun 20, 2019 at 03:02:04PM +0200, Ard Biesheuvel wrote:
>>
>> It also depend on how realistic it is that we will need to support
>> arbitrary sector sizes in the future. I mean, if we decide today that
>> essiv() uses an implicit sector size of 4k, w
On 20/06/2019 15:52, Ard Biesheuvel wrote:
Does this include configurations that combine authenc with essiv?
>>>
>>> Hm, seems that we are missing these in luks2-integrity-test. I'll add them
>>> there.
>>>
>>> I also used this older test
>>> https://gitlab.com/omos/dm-crypt-test-scripts/blob
On 23/06/2019 12:12, Herbert Xu wrote:
> On Sun, Jun 23, 2019 at 11:30:41AM +0200, Ard Biesheuvel wrote:
>>
>> So with that in mind, I think we should decouple the multi-sector
>> discussion and leave it for a followup series, preferably proposed by
>> someone who also has access to some hardware t
On 21/06/2019 10:09, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> Replace the explicit ESSIV handling in the dm-crypt driver with calls
> into the crypto API, which now possesses the capability to perform
> this processing within the crypto subsystem.
I tried a few crazy dm-crypt configurati
On 25/06/2019 20:20, Mike Snitzer wrote:
> On Wed, Jun 19 2019 at 3:10pm -0400,
> Jaskaran Khurana wrote:
>
>> The verification is to support cases where the roothash is not secured by
>> Trusted Boot, UEFI Secureboot or similar technologies.
>> One of the use cases for this is for dm-verity vol
Hi,
I tried to test test the patch, two comments below.
On 19/06/2019 21:10, Jaskaran Khurana wrote:
> The verification is to support cases where the roothash is not secured by
> Trusted Boot, UEFI Secureboot or similar technologies.
> One of the use cases for this is for dm-verity volumes mounte
On 28/06/2019 05:00, Eric Biggers wrote:
>> Hello Eric,
>>
>> This started with a config (see V4). We didnot want scripts that pass this
>> parameter to suddenly stop working if for some reason the verification is
>> turned off so the optional parameter was just parsed and no validation
>> happened
> cc->iv_size = crypto_aead_ivsize(any_tfm_aead(cc));
> } else
> cc->iv_size = crypto_skcipher_ivsize(any_tfm(cc));
Otherwise
Reviewed-by: Milan Broz
Thanks,
Milan
gt;= CRYPTO_MAX_ALG_NAME)
> + goto bad_mem;
Hm, nitpicking, but goto from only one place while we have another -ENOMEM
above...
Just place this here without goto?
> + ti->error = "Cannot allocate cipher string";
> + return -ENOMEM;
Otherwise
Reviewed-by: Milan Broz
Thanks,
Milan
On 29/06/2019 06:01, James Morris wrote:
> On Thu, 27 Jun 2019, Eric Biggers wrote:
>
>> I don't understand your justification for this feature.
>>
>> If userspace has already been pwned severely enough for the attacker to be
>> executing arbitrary code with CAP_SYS_ADMIN (which is what the device
The URL is no longer valid and the comment is obsolete anyway
(the plumb IV was never used).
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index c6d41a7e89c9..96ead4492787 100644
--- a
This IV is used in some BitLocker devices with CBC encryption mode.
NOTE: maybe we need to use another crypto API if the bare cipher
API is going to be deprecated.
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 82 ++-
1 file changed, 81
: Milan Broz
---
drivers/md/dm-crypt.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 1b16d34bb785..c6d41a7e89c9 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2158,6 +2158,14 @@ static int
makes sense only for FDE (old compatible Bitlocker devices),
I really do not want this to be shared in some crypto module...
What API should I use here? Sync skcipher? Is the crypto_cipher API
really a problem in this case?
Thanks,
Milan
On 04/07/2019 15:10, Milan Broz wrote:
> This IV is used
On 04/07/2019 16:30, Ard Biesheuvel wrote:
> On Thu, 4 Jul 2019 at 16:28, Ard Biesheuvel wrote:
>>
>> (+ Eric)
>>
>> On Thu, 4 Jul 2019 at 15:29, Milan Broz wrote:
>>>
>>> Hi Herbert,
>>>
>>> I have a question about the crypto_cipher
This IV is used in some BitLocker devices with CBC encryption mode.
IV is encrypted little-endian byte-offset (with the same key and cipher
as the volume).
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 82 ++-
1 file changed, 81 insertions(+), 1
: Milan Broz
---
drivers/md/dm-crypt.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 0fd3ca9bfe54..0e24079e97da 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -2158,6 +2158,14 @@ static int
The URL is no longer valid and the comment is obsolete anyway
(the plumb IV was never used).
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 0e24079e97da..c567e13a0e5f 100644
--- a
On 12/07/2019 19:33, Jaskaran Singh Khurana wrote:
>
> Hello Milan,
>
>> Changes in v6:
>>
>> Address comments from Milan Broz and Eric Biggers on v5.
>>
>> -Keep the verification code under config DM_VERITY_VERIFY_ROOTHASH_SIG.
>>
>> -Chang
reviewing this patch. Could you please
> add Reviewed-by/Tested-by tag to the patch.
ok, you can add
Tested-and-Reviewed-by: Milan Broz
or just use the version on my git, I already updated few lines because
of recent kernel changes, mainly the revert of keyring changes, tested patch is
here
On 18/07/2019 09:21, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 09:15:39AM +0200, Ard Biesheuvel wrote:
>>
>> Not just the generic implementation: there are numerous synchronous
>> and asynchronous implementations of xts(aes) in the kernel that would
>> have to be fixed, while there are no in-kern
On 18/07/2019 12:40, Pascal Van Leeuwen wrote:
...
>> See the reference in generic code - the 3rd line - link to the IEEE standard.
>> We do not implement it properly - for more than 12 years!
>>
>
> Full XTS is XEX-TCB-CTS so the proper terminology for "XTS without CTS" would
> be XEX-TCB.
> But
On 20/07/2019 08:58, Eric Biggers wrote:
> On Thu, Jul 18, 2019 at 01:19:41PM +0200, Milan Broz wrote:
>> Also, I would like to avoid another "just because it is nicer" module
>> dependence (XTS->XEX->ECB).
>> Last time (when XTS was reimplemented
On 27/07/2019 07:39, Ard Biesheuvel wrote:
> Thanks for the additional test vectors. They work fine with my SIMD
> implementations for ARM [0], so this looks like it might be a CAAM
> problem, not a problem with the test vectors.
>
> I will try to find some time today to run them through OpenSSL t
On 06/08/2019 10:02, Ard Biesheuvel wrote:
> The EBOIV IV mode reuses the same AES encryption key that is used for
> encrypting the data, and uses it to perform a single block encryption
> of the byte offset to produce the IV.
>
> Since table-based AES is known to be susceptible to known-plaintext
On 06/08/2019 14:17, Ard Biesheuvel wrote:
> On Tue, 6 Aug 2019 at 13:43, Milan Broz wrote:
>>
>> On 06/08/2019 10:02, Ard Biesheuvel wrote:
>>> The EBOIV IV mode reuses the same AES encryption key that is used for
>>> encrypting the data, and uses it to perform
On 07/08/2019 07:50, Ard Biesheuvel wrote:
> Instead of instantiating a separate cipher to perform the encryption
> needed to produce the IV, reuse the skcipher used for the block data
> and invoke it one additional time for each block to encrypt a zero
> vector and use the output as the IV.
>
> F
; be exposed to other subsystems, such as the bare cipher API.
>
> Signed-off-by: Ard Biesheuvel
For now I have just pair of images here to test, but seems checksums are ok.
Tested-by: Milan Broz
I talked with Mike already, so it should go through DM tree now.
On 08/08/2019 11:31, Pascal Van Leeuwen wrote:
>> -Original Message-
>> From: Eric Biggers
>> Sent: Thursday, August 8, 2019 10:31 AM
>> To: Pascal Van Leeuwen
>> Cc: Ard Biesheuvel ; linux-cry...@vger.kernel.org;
>> herb...@gondor.apana.org.au; a...@redhat.com; snit...@redhat.com;
>> dm
On 10/08/2019 06:39, Ard Biesheuvel wrote:
> Truncated IVs are a huge issue, since we already expose the correct
> API via AF_ALG (without any restrictions on how many of the IV bits
> are populated), and apparently, if your AF_ALG request for xts(aes)
> happens to be fulfilled by the CAAM driver a
Hi,
On 10/08/2019 11:40, Ard Biesheuvel wrote:
> Replace the explicit ESSIV handling in the dm-crypt driver with calls
> into the crypto API, which now possesses the capability to perform
> this processing within the crypto subsystem.
>
> Signed-off-by: Ard Biesheuvel
> ---
> drivers/md/Kconfig
On 12/08/2019 08:54, Ard Biesheuvel wrote:
> On Mon, 12 Aug 2019 at 09:33, Milan Broz wrote:
>> Try for example
>> # cryptsetup luksFormat /dev/sdc -c aes-cbc-essiv:sha256 --integrity
>> hmac-sha256 -q -i1
>>
>> It should produce Crypto API string
>> aut
On 12/08/2019 09:50, Ard Biesheuvel wrote:
> On Mon, 12 Aug 2019 at 10:44, Milan Broz wrote:
>>
>> On 12/08/2019 08:54, Ard Biesheuvel wrote:
>>> On Mon, 12 Aug 2019 at 09:33, Milan Broz wrote:
>>>> Try for example
>>>> # cryptsetup luksFor
Hi Ard,
On 15/08/2019 21:28, Ard Biesheuvel wrote:
> Changes since v10:
> - Drop patches against fscrypt and dm-crypt - these will be routed via the
> respective maintainer trees during the next cycle
I tested the previous dm-crypt patches (I also try to keep them in my
kernel.org tree),
it wo
On 16/08/2019 10:18, Ard Biesheuvel wrote:
> On Fri, 16 Aug 2019 at 10:29, Milan Broz wrote:
>>
>> Hi Ard,
>>
>> On 15/08/2019 21:28, Ard Biesheuvel wrote:
>>> Changes since v10:
>>> - Drop patches against fscrypt and dm-crypt - these will be rou
On 21/08/2019 08:42, boojin.kim wrote:
> This patch supports dm-crypt to use diskcipher in a specific ivmode
> (disk or fmp).
> Dm-crypt allocates diskcipher and sets the key on it.
> Then, dm-crypt sets diskcipher into BIO and submits the BIO without
> any additional data encryption.
NACK.
The w
On 03/09/2019 20:58, Mike Snitzer wrote:
> On Mon, Aug 19 2019 at 10:17am -0400,
> Ard Biesheuvel wrote:
>
>> Only the ESSIV IV generation mode used to use cc->cipher so it could
>> instantiate the bare cipher used to encrypt the IV. However, this is
>> now taken care of by the ESSIV template, an
On 16/09/2019 20:01, Christoph Hellwig wrote:
> On Mon, Sep 16, 2019 at 05:55:42AM -0400, Mikulas Patocka wrote:
>> This patch introduces a new ioctl DM_GET_TARGET_VERSION. It will load a
>> target that is specified in the "name" entry in the parameter structure
>> and return its version.
>>
>> Thi
On 20/09/2019 19:37, Mike Snitzer wrote:
> On Fri, Sep 20 2019 at 11:44am -0400,
> Thibaut Sautereau wrote:
>
>> Hi,
>>
>> I just got a dm-crypt "crypt: Error allocating crypto tfm" error when
>> trying to "cryptsetup open" a volume. I found out that it was only
>> happening when I disabled CONFI
On 23/09/2019 10:20, Thibaut Sautereau wrote:
>
> On top of that, there's no hint in kernel logs about a particular
> algorithm, feature or Kconfig option that could be missing. Do we really
> expect people simply tuning their kernel configuration to go and read
> the source code to ensure they ar
not modify original bio data for write (before
encryption), an additional internal flag to pre-process data is added.
Signed-off-by: Milan Broz
---
drivers/md/dm-crypt.c | 323 +-
1 file changed, 319 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm
=941051
Signed-off-by: Milan Broz
Cc: # v4.12+
---
drivers/md/dm-crypt.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index f9370a1a574b..fd30143dca91 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
On 04/07/2017 12:47 PM, Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
...
> Tests with dd [direct i/o]
>
> Sequent
On 04/11/2017 05:33 PM, Enric Balletbo i Serra wrote:
> From: Will Drewry
>
> Version 0 of the on-disk format is compatible with the format used in the
> Chromium OS. This patch adds support for this version.
>
> Format type 0 is the original Chrome OS version, whereas the format type 1
> is cur
On 04/14/2017 06:03 PM, Logan Gunthorpe wrote:
>
>
> On 14/04/17 02:39 AM, Christoph Hellwig wrote:
>> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
>>> Very straightforward conversion to the new function in all four spots.
>>
>> I think the right fix here is to switch dm-crypt
On 04/24/2017 09:34 AM, Bongkyu Kim wrote:
> This patch introduces deferred hash checking for dm-verity.
> In case of restart and logging mode, I/O return first and hash checking is
> deferred. It can improve dm-verity's performance greatly.
>
> This is my testing on qualcomm snapdragon 821 platfo
Add more descriptive text to explain what it the dm-integrity
when it should be enabled.
Signed-off-by: Milan Broz
---
drivers/md/Kconfig | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 7468a22f9d10..3e96fccbbdb2
The switch just enables dm-integrity module but it makes
configuration more logic and user friendly.
Signed-off-by: Milan Broz
---
drivers/md/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index 3e96fccbbdb2..134f885c6be1 100644
Hi Gilad,
seems this OOPs is caused by async crypto hash changes in 4.12 for dm-verity.
Could you please check if it is some known problem?
Fedora rawhide x86_64 (with 4.12rc patches) crashes always,
running verity-compat-test from cryptsetup testsuite is enough to trigger this.
I am not able t
On 05/18/2017 08:55 AM, Gilad Ben-Yossef wrote:
> On Thu, May 18, 2017 at 9:37 AM, Milan Broz wrote:
>> Hi Gilad,
>>
>> seems this OOPs is caused by async crypto hash changes in 4.12 for dm-verity.
>>
>
> Oy, that is not good.
>
>> Could you please ch
verity: switch to using asynchronous hash crypto API")
> CC: Milan Broz
Tested-by: Milan Broz
Thanks for quick fix!
Mike: this must go to 4.12rc (only).
m.
> ---
> drivers/md/dm-verity-target.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On 05/24/2017 11:29 AM, Abdul Haleem wrote:
> Hi
>
> commit cf22cd5f3a: dm crypt: add cryptographic data integrity protection
> suspected to be bad.
Isn't this false positive? That commit changes only dm-crypt and that module
seems not to be even loaded...
(Moreover config has disabled block inte
The big-endian IV is needed to map images from extracted
disks that are used in some external (on-chip FDE) disk encryption drives.
(For example for data recovery from external USB/SATA drives that
supports "internal" encryption.)
Signed-off-by: Milan Broz
---
drivers/md/dm-cr
On 06/15/2017 01:40 AM, Michael Halcrow wrote:
> Several file systems either have already implemented encryption or are
> in the process of doing so. This addresses usability and storage
> isolation requirements on mobile devices and in multi-tenant
> environments.
>
> While distinct keys locked
On 06/15/2017 07:24 PM, Michael Halcrow wrote:
...
>> If this is accepted, we basically allow attacker to trick system to
>> write plaintext to media just by setting this flag. This must never
>> ever happen with FDE - BY DESIGN.
>
> That's an important point. This expands the attack surface to i
1 - 100 of 241 matches
Mail list logo
