Re: Very slow unlockall()

On 01/02/2021 19:55, Vlastimil Babka wrote: > On 2/1/21 7:00 PM, Milan Broz wrote: >> On 01/02/2021 14:08, Vlastimil Babka wrote: >>> On 1/8/21 3:39 PM, Milan Broz wrote: >>>> On 08/01/2021 14:41, Michal Hocko wrote: >>>>> On Wed 06-01-21 16:20:15, Mila

Re: Very slow unlockall()

On 01/02/2021 14:08, Vlastimil Babka wrote: > On 1/8/21 3:39 PM, Milan Broz wrote: >> On 08/01/2021 14:41, Michal Hocko wrote: >>> On Wed 06-01-21 16:20:15, Milan Broz wrote: >>>> Hi, >>>> >>>> we use mlockall(MCL_CURRENT | MCL_FUTURE) /

Re: Very slow unlockall()

On 08/01/2021 15:39, Milan Broz wrote: > On 08/01/2021 14:41, Michal Hocko wrote: >> On Wed 06-01-21 16:20:15, Milan Broz wrote: >>> Hi, >>> >>> we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code >>> and someone tried to

Re: Very slow unlockall()

On 08/01/2021 14:41, Michal Hocko wrote: > On Wed 06-01-21 16:20:15, Milan Broz wrote: >> Hi, >> >> we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code >> and someone tried to use it with hardened memory allocator library. >> >>

Very slow unlockall()

Hi, we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code and someone tried to use it with hardened memory allocator library. Execution time was increased to extreme (minutes) and as we found, the problem is in munlockall(). Here is a plain reproducer for the core without

Re: [PATCH v3 1/4] crypto: add eboiv as a crypto API template

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

Re: [PATCH 3/4] dm crypt: switch to EBOIV crypto API template

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

Re: [PATCH 3/4] dm crypt: switch to EBOIV crypto API template

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

Re: [PATCH 3/4] dm crypt: switch to EBOIV crypto API template

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

Re: [PATCH v2] dm verity: Add support for signature verification with 2nd keyring

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? or

Re: [PATCH v3 2/2] dm-crypt: collect data and submit to DM to measure

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

Re: New mode DM-Verity error handling

ion 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:58, M

Re: New mode DM-Verity error handling

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

[PATCH v2] tpm: Fix null pointer dereference on chip register error path

: 719b7d81f204 ("tpm: introduce tpm_chip_start() and tpm_chip_stop()") Cc: sta...@vger.kernel.org # v5.1+ Signed-off-by: Milan Broz --- drivers/char/tpm/tpm-chip.c | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/ch

Re: [PATCH v2 0/2] tty: erase buffers when the kernel is done with it.

On 04/10/2018 20:06, Greg Kroah-Hartman wrote: > azlig and Milan Broz reported that when the tty layer is done with a > buffer, the data can hang around in it for a very long time. That > sometimes can "leak" to userspace under some conditions. > > Because of this, jus

Re: [PATCH v2 0/2] tty: erase buffers when the kernel is done with it.

On 04/10/2018 20:06, Greg Kroah-Hartman wrote: > azlig and Milan Broz reported that when the tty layer is done with a > buffer, the data can hang around in it for a very long time. That > sometimes can "leak" to userspace under some conditions. > > Because of this, jus

Re: [PATCH 2/2] tty: wipe buffer if not echoing data

e to userspace. It can be retrieved from memory dump later, even after the crypt mapping is destroyed. Almost all userspace tools working with passphrases through tty access have the same problem here. > This mirrors the logic that the audit code has. > > Reported-by: aszlig > Tested-by: Mil

Re: [PATCH 2/2] tty: wipe buffer if not echoing data

e to userspace. It can be retrieved from memory dump later, even after the crypt mapping is destroyed. Almost all userspace tools working with passphrases through tty access have the same problem here. > This mirrors the logic that the audit code has. > > Reported-by: aszlig > Tested-by: Mil

Re: [PATCH] md: dm-crypt: Add Inline Encryption support for dmcrypt

On 05/28/2018 03:01 PM, Ladvine D Almeida wrote: > > This patch adds new option > -- perform_inline_encrypt > that set the option inside dmcrypt to use inline encryption for > the configured mapping. I want to introduce inline encryption support > in the UFS Host Controller driver. The usage

Re: [PATCH] md: dm-crypt: Add Inline Encryption support for dmcrypt

On 05/28/2018 03:01 PM, Ladvine D Almeida wrote: > > This patch adds new option > -- perform_inline_encrypt > that set the option inside dmcrypt to use inline encryption for > the configured mapping. I want to introduce inline encryption support > in the UFS Host Controller driver. The usage

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote: ... >> Are there other crypto drivers doing this? > > I thought the exact same thing until I ran into a presentation about the s390 > secure keys implementation. I basically imitated their use (or abuse?) > of the Crypto API > assuming it is the way

Re: [PATCH 2/2] crypto: ccree: enable support for hardware keys

On 03/31/2018 07:30 PM, Gilad Ben-Yossef wrote: ... >> Are there other crypto drivers doing this? > > I thought the exact same thing until I ran into a presentation about the s390 > secure keys implementation. I basically imitated their use (or abuse?) > of the Crypto API > assuming it is the way

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Mike and others, did anyone even try to run veritysetup tests? We have verity-compat-test in our testsuite, is has even basic FEC tests included. We just added userspace verification of FEC RS codes to compare if kernel behaves the same. I tried to apply three last dm-verity patches from

Re: [dm-devel] [PATCH 2/2] md: dm-verity: allow parallel processing of bio blocks

Mike and others, did anyone even try to run veritysetup tests? We have verity-compat-test in our testsuite, is has even basic FEC tests included. We just added userspace verification of FEC RS codes to compare if kernel behaves the same. I tried to apply three last dm-verity patches from

Re: [PATCH] Add an option to dm-verity to validate hashes at most once

On 03/07/2018 12:14 AM, Patrik Torstensson wrote: > Add an option to dm-verity to validate hashes at most once > to allow platforms that is CPU/memory contraint to be > protected by dm-verity against offline attacks. > > The option introduces a bitset that is used to check if > a block has been

Re: [PATCH] Add an option to dm-verity to validate hashes at most once

On 03/07/2018 12:14 AM, Patrik Torstensson wrote: > Add an option to dm-verity to validate hashes at most once > to allow platforms that is CPU/memory contraint to be > protected by dm-verity against offline attacks. > > The option introduces a bitset that is used to check if > a block has been

Re: [dm-devel] DM Regression in 4.16-rc1 - read() returns data when it shouldn't

On 02/15/2018 01:07 AM, NeilBrown wrote: > > And looking again at the code, it doesn't seem so bad. I was worried > about reassigning ci.io->orig_bio after calling > __split_and_process_non_flush(), but the important thing is to set it > before the last dec_pending() call, and the code gets that

Re: [dm-devel] DM Regression in 4.16-rc1 - read() returns data when it shouldn't

On 02/15/2018 01:07 AM, NeilBrown wrote: > > And looking again at the code, it doesn't seem so bad. I was worried > about reassigning ci.io->orig_bio after calling > __split_and_process_non_flush(), but the important thing is to set it > before the last dec_pending() call, and the code gets that

DM Regression in 4.16-rc1 - read() returns data when it shouldn't

Hi, the commit (found by bisect) commit 18a25da84354c6bb655320de6072c00eda6eb602 Author: NeilBrown Date: Wed Sep 6 09:43:28 2017 +1000 dm: ensure bio submission follows a depth-first tree walk cause serious regression while reading from DM device. The reproducer

DM Regression in 4.16-rc1 - read() returns data when it shouldn't

Hi, the commit (found by bisect) commit 18a25da84354c6bb655320de6072c00eda6eb602 Author: NeilBrown Date: Wed Sep 6 09:43:28 2017 +1000 dm: ensure bio submission follows a depth-first tree walk cause serious regression while reading from DM device. The reproducer is below,

Re: [PATCH] dm-crypt, dm-integrity: allow unaligned bv_offset

cussion - we wanted to have dm-crypt and dm-integrity to check the same thing, just to trigger possible data corruption, but obviously it was incorrect check.) It must go to stable well, I think there are possibly more situations we broke for dm-crypt by this. Reviewed-by: Milan Broz <gmazyl...@gmail.com> m.

Re: [PATCH] dm-crypt, dm-integrity: allow unaligned bv_offset

me thing, just to trigger possible data corruption, but obviously it was incorrect check.) It must go to stable well, I think there are possibly more situations we broke for dm-crypt by this. Reviewed-by: Milan Broz m.

Re: [BUG][next-20170523][Bisected cf22cd5f3a] kernel oops while running trinity fuzzer

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

Re: [BUG][next-20170523][Bisected cf22cd5f3a] kernel oops while running trinity fuzzer

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

Re: [PATCH] dm verity: fix no salt used use case

mcson...@redhat.com> > Fixes: d1ac3ff ("dm verity: switch to using asynchronous hash crypto API") > CC: Milan Broz <gmazyl...@gmail.com> Tested-by: Milan Broz <gmazyl...@gmail.com> Thanks for quick fix! Mike: this must go to 4.12rc (only). m. > --- > drivers

Re: [PATCH] dm verity: fix no salt used use case

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

[PATCH] dm-integrity: Add proper description of module to KConfig.

Add more descriptive text to explain what it the dm-integrity when it should be enabled. Signed-off-by: Milan Broz <gmazyl...@gmail.com> --- drivers/md/Kconfig | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig

[PATCH] dm-integrity: Add proper description of module to KConfig.

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

Re: DM_INTEGRITY Kconfig help (was: Re: dm: add integrity target)

On 05/04/2017 08:03 AM, Geert Uytterhoeven wrote: >> +config DM_INTEGRITY >> + tristate "Integrity target" >> + depends on BLK_DEV_DM >> + select BLK_DEV_INTEGRITY >> + select DM_BUFIO >> + select CRYPTO >> + select ASYNC_XOR >> + ---help--- >> +

Re: DM_INTEGRITY Kconfig help (was: Re: dm: add integrity target)

On 05/04/2017 08:03 AM, Geert Uytterhoeven wrote: >> +config DM_INTEGRITY >> + tristate "Integrity target" >> + depends on BLK_DEV_DM >> + select BLK_DEV_INTEGRITY >> + select DM_BUFIO >> + select CRYPTO >> + select ASYNC_XOR >> + ---help--- >> +

Re: [PATCH] dm verity: deferred hash checking for restart/logging mode

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

Re: [PATCH] dm verity: deferred hash checking for restart/logging mode

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

Re: [PATCH 5/5] dm verity: add support for version 0 of the on-disk format

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

Re: [PATCH 5/5] dm verity: add support for version 0 of the on-disk format

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

Re: [RFC PATCH v5] IV Generation algorithms for dm-crypt

On 04/07/2017 12:47 PM, Binoy Jayan wrote: > === > dm-crypt optimization for larger block sizes > === ... > Tests with dd [direct i/o] > >

Re: [RFC PATCH v5] IV Generation algorithms for dm-crypt

On 04/07/2017 12:47 PM, Binoy Jayan wrote: > === > dm-crypt optimization for larger block sizes > === ... > Tests with dd [direct i/o] > >

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 02:04 PM, Milan Broz wrote: > On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: > ... > >> I can certainly understand if you don't wont to take the patch until >> we have results with >> dm-crypt itself but the difference between 8 separate invocati

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 02:04 PM, Milan Broz wrote: > On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: > ... > >> I can certainly understand if you don't wont to take the patch until >> we have results with >> dm-crypt itself but the difference between 8 separate invocati

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: ... > I can certainly understand if you don't wont to take the patch until > we have results with > dm-crypt itself but the difference between 8 separate invocation of > the engine for 512 > bytes of XTS and a single invocation for 4KB are pretty

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote: ... > I can certainly understand if you don't wont to take the patch until > we have results with > dm-crypt itself but the difference between 8 separate invocation of > the engine for 512 > bytes of XTS and a single invocation for 4KB are pretty

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote: > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz <gmazyl...@gmail.com> wrote: >> >> On 02/22/2017 07:12 AM, Binoy Jayan wrote: >>> >>> I was wondering if this is near to be ready for submission (apart from &

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 03/01/2017 09:30 AM, Gilad Ben-Yossef wrote: > On Tue, Feb 28, 2017 at 11:05 PM, Milan Broz wrote: >> >> On 02/22/2017 07:12 AM, Binoy Jayan wrote: >>> >>> I was wondering if this is near to be ready for submission (apart from >>> the testmgr.c &

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 02/22/2017 07:12 AM, Binoy Jayan wrote: > > I was wondering if this is near to be ready for submission (apart from > the testmgr.c > changes) or I need to make some changes to make it similar to the IPSec > offload? I just tried this and except it registers the IV for every new device again,

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

On 02/22/2017 07:12 AM, Binoy Jayan wrote: > > I was wondering if this is near to be ready for submission (apart from > the testmgr.c > changes) or I need to make some changes to make it similar to the IPSec > offload? I just tried this and except it registers the IV for every new device again,

Re: dm-crypt optimization

On 12/20/2016 10:41 AM, Binoy Jayan wrote: > At a high level the goal is to maximize the size of data blocks that get > passed > to hardware accelerators, minimizing the overhead from setting up and tearing > down operations in the hardware. Currently dm-crypt itself is a big blocker as > it

Re: dm-crypt optimization

On 12/20/2016 10:41 AM, Binoy Jayan wrote: > At a high level the goal is to maximize the size of data blocks that get > passed > to hardware accelerators, minimizing the overhead from setting up and tearing > down operations in the hardware. Currently dm-crypt itself is a big blocker as > it

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

On 12/13/2016 09:49 AM, Binoy Jayan wrote: > Currently, the iv generation algorithms are implemented in dm-crypt.c. > The goal is to move these algorithms from the dm layer to the kernel > crypto layer by implementing them as template ciphers so they can be > implemented in hardware for

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

On 12/13/2016 09:49 AM, Binoy Jayan wrote: > Currently, the iv generation algorithms are implemented in dm-crypt.c. > The goal is to move these algorithms from the dm layer to the kernel > crypto layer by implementing them as template ciphers so they can be > implemented in hardware for

Re: dm-crypt accepts '+' in the key

On 11/12/2016 09:20 PM, Mikulas Patocka wrote: > Hi > > dm-crypt uses the function kstrtou8 to decode the encryption key. kstrtou8 > calls kstrtoull and kstrtoull skips the first character if it is '+'. > > Consequently, it is possible to load keys with '+' in it. For example, > this is

Re: dm-crypt accepts '+' in the key

On 11/12/2016 09:20 PM, Mikulas Patocka wrote: > Hi > > dm-crypt uses the function kstrtou8 to decode the encryption key. kstrtou8 > calls kstrtoull and kstrtoull skips the first character if it is '+'. > > Consequently, it is possible to load keys with '+' in it. For example, > this is

Re: System freezes after OOM

On 07/14/2016 11:09 AM, Michal Hocko wrote: > On Wed 13-07-16 11:21:41, Mikulas Patocka wrote: >> >> >> On Wed, 13 Jul 2016, Milan Broz wrote: >> >>> On 07/13/2016 02:50 PM, Michal Hocko wrote: >>>> On Wed 13-07-16 13:10:06, Michal Hocko wrote: >&

Re: System freezes after OOM

On 07/14/2016 11:09 AM, Michal Hocko wrote: > On Wed 13-07-16 11:21:41, Mikulas Patocka wrote: >> >> >> On Wed, 13 Jul 2016, Milan Broz wrote: >> >>> On 07/13/2016 02:50 PM, Michal Hocko wrote: >>>> On Wed 13-07-16 13:10:06, Michal Hocko wrote: >&

Re: System freezes after OOM

On 07/13/2016 02:50 PM, Michal Hocko wrote: > On Wed 13-07-16 13:10:06, Michal Hocko wrote: >> On Tue 12-07-16 19:44:11, Mikulas Patocka wrote: > [...] >>> As long as swapping is in progress, the free memory is below the limit >>> (because the swapping activity itself consumes any memory over the

Re: System freezes after OOM

On 07/13/2016 02:50 PM, Michal Hocko wrote: > On Wed 13-07-16 13:10:06, Michal Hocko wrote: >> On Tue 12-07-16 19:44:11, Mikulas Patocka wrote: > [...] >>> As long as swapping is in progress, the free memory is below the limit >>> (because the swapping activity itself consumes any memory over the

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 05/27/2016 09:04 AM, Baolin Wang wrote: > Hi Milan, > > On 27 May 2016 at 14:31, Milan Broz <gmazyl...@gmail.com> wrote: >> On 05/25/2016 08:12 AM, Baolin Wang wrote: >>> Now some cipher hardware engines prefer to handle bulk block rather than one >>>

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 05/27/2016 09:04 AM, Baolin Wang wrote: > Hi Milan, > > On 27 May 2016 at 14:31, Milan Broz wrote: >> On 05/25/2016 08:12 AM, Baolin Wang wrote: >>> Now some cipher hardware engines prefer to handle bulk block rather than one >>> sector (512 bytes) create

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 05/25/2016 08:12 AM, Baolin Wang wrote: > Now some cipher hardware engines prefer to handle bulk block rather than one > sector (512 bytes) created by dm-crypt, cause these cipher engines can handle > the intermediate values (IV) by themselves in one bulk block. This means we > can increase the

Re: [RFC 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On 05/25/2016 08:12 AM, Baolin Wang wrote: > Now some cipher hardware engines prefer to handle bulk block rather than one > sector (512 bytes) created by dm-crypt, cause these cipher engines can handle > the intermediate values (IV) by themselves in one bulk block. This means we > can increase the

Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework

> > As a DM mainatiner my only contribution to this line of discussion was > relative to your proposal to train the dm-crypt target (which is > bio-based) to also provide request-based support, see: > https://www.redhat.com/archives/dm-devel/2015-November/msg00112.html > > But follow-up di

Re: [PATCH v2 0/4] Introduce bulk mode for crypto engine framework

on was > relative to your proposal to train the dm-crypt target (which is > bio-based) to also provide request-based support, see: > https://www.redhat.com/archives/dm-devel/2015-November/msg00112.html > > But follow-up discussion occured, primarily with Milan Broz, which led > t

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

On 02/21/2016 05:40 PM, Milan Broz wrote: > On 02/20/2016 03:33 PM, Thomas D. wrote: >> Hi, >> >> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected. >> >> v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3. >> >> v3.

Re: [PATCH] Re: Broken userspace crypto in linux-4.1.18

On 02/21/2016 05:40 PM, Milan Broz wrote: > On 02/20/2016 03:33 PM, Thomas D. wrote: >> Hi, >> >> FYI: v3.10.97, v3.14.61 and 3.18.27 are also affected. >> >> v4.3.6 works. Looks like the patch set is only compatible with >=linux-4.3. >> >> v3.

Re: [PATCH 1/2] crypto: af_alg - Add nokey compatibility path

On 01/04/2016 05:35 AM, Herbert Xu wrote: > On Sun, Jan 03, 2016 at 10:42:28AM +0100, Milan Broz wrote: >> >> yes, basically it prepares socket()/bind()/accept() and then it calls setkey >> once. >> (I'll try to fix in next releases to call setkey first though.) &

Re: [PATCH 1/2] crypto: af_alg - Add nokey compatibility path

On 01/04/2016 05:35 AM, Herbert Xu wrote: > On Sun, Jan 03, 2016 at 10:42:28AM +0100, Milan Broz wrote: >> >> yes, basically it prepares socket()/bind()/accept() and then it calls setkey >> once. >> (I'll try to fix in next releases to call setkey first though.) &

Re: next-20151231 - aes crypto algorithm went missing?

On 01/03/2016 06:34 AM, Valdis Kletnieks wrote: > So booting into a next-20151222 kernel, I can mount an external drive > that uses cryptLuks. I try -1231, and I get this failure: > > Failed to setup dm-crypt key mapping for device /dev/sdb2. > Check that kernel supports aes-cbc-essiv:sha256

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively >> using that code. >> This is clear userspace breakage which should not happen thi

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively >> using that code. >> This is clear userspace breakage which should not happen thi

Re: next-20151231 - aes crypto algorithm went missing?

On 01/03/2016 06:34 AM, Valdis Kletnieks wrote: > So booting into a next-20151222 kernel, I can mount an external drive > that uses cryptLuks. I try -1231, and I get this failure: > > Failed to setup dm-crypt key mapping for device /dev/sdb2. > Check that kernel supports aes-cbc-essiv:sha256

Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On 12/17/2015 08:37 AM, Baolin Wang wrote: > Hi Milan, > > On 16 December 2015 at 16:08, Milan Broz wrote: >> On 12/16/2015 04:18 AM, Baolin Wang wrote: >>> From the dm-crypt performance report, we found it shows low efficiency >>> with crypto engine for some mod

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/02/2016 09:03 PM, Stephan Mueller wrote: > Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz: > > Hi Milan, > ... >>> Hi Herbert, >>> >>> this patch breaks userspace in cryptsetup... >>> >>> We use algif_skcipher in cryptsetu

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/02/2016 12:52 PM, Milan Broz wrote: > On 12/25/2015 08:40 AM, Herbert Xu wrote: >> Dmitry Vyukov wrote: >>> >>> I am testing with your two patches: >>> crypto: algif_skcipher - Use new skcipher interface >>> crypto: algif_skcipher

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 12/25/2015 08:40 AM, Herbert Xu wrote: > Dmitry Vyukov wrote: >> >> I am testing with your two patches: >> crypto: algif_skcipher - Use new skcipher interface >> crypto: algif_skcipher - Require setkey before accept(2) >> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d (Dec 23). > > You

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/02/2016 12:52 PM, Milan Broz wrote: > On 12/25/2015 08:40 AM, Herbert Xu wrote: >> Dmitry Vyukov <dvyu...@google.com> wrote: >>> >>> I am testing with your two patches: >>> crypto: algif_skcipher - Use new skcipher interface >>> cryp

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 12/25/2015 08:40 AM, Herbert Xu wrote: > Dmitry Vyukov wrote: >> >> I am testing with your two patches: >> crypto: algif_skcipher - Use new skcipher interface >> crypto: algif_skcipher - Require setkey before accept(2) >> on top of a88164345b81292b55a8d4829fdd35c8d611cd7d

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/02/2016 09:03 PM, Stephan Mueller wrote: > Am Samstag, 2. Januar 2016, 15:41:34 schrieb Milan Broz: > > Hi Milan, > ... >>> Hi Herbert, >>> >>> this patch breaks userspace in cryptsetup... >>> >>> We use algif_skcipher in cryptsetu

Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On 12/17/2015 08:37 AM, Baolin Wang wrote: > Hi Milan, > > On 16 December 2015 at 16:08, Milan Broz <gmazyl...@gmail.com> wrote: >> On 12/16/2015 04:18 AM, Baolin Wang wrote: >>> From the dm-crypt performance report, we found it shows low efficiency >>> wit

Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On 12/16/2015 04:18 AM, Baolin Wang wrote: > From the dm-crypt performance report, we found it shows low efficiency > with crypto engine for some mode (like ecb or xts mode). Because in dm > crypt, it will map the IO data buffer with scatterlist, and send the > scatterlist of one bio to the

Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

On 12/16/2015 04:18 AM, Baolin Wang wrote: > From the dm-crypt performance report, we found it shows low efficiency > with crypto engine for some mode (like ecb or xts mode). Because in dm > crypt, it will map the IO data buffer with scatterlist, and send the > scatterlist of one bio to the

Re: [PATCH 2/2] md: dm-crypt: Optimize the dm-crypt for XTS mode

On 12/15/2015 03:56 AM, Baolin Wang wrote: >>> + /* >>> + * Here we need to check if it can be encrypted or decrypted with >>> + * bulk block, which means these encryption modes don't need IV or >>> + * just need one initial IV. For bulk mode, we can expand the >>> + *

Re: [PATCH 2/2] md: dm-crypt: Optimize the dm-crypt for XTS mode

On 12/15/2015 03:56 AM, Baolin Wang wrote: >>> + /* >>> + * Here we need to check if it can be encrypted or decrypted with >>> + * bulk block, which means these encryption modes don't need IV or >>> + * just need one initial IV. For bulk mode, we can expand the >>> + *

Re: [PATCH 2/2] md: dm-crypt: Optimize the dm-crypt for XTS mode

On 12/14/2015 09:23 AM, Baolin Wang wrote: > In now dm-crypt code, it is ineffective to map one bio with just only > one scatterlist at one time for XTS mode. We can use multiple scatterlists > to map the whole bio and send all scatterlists of one bio to crypto engine > to encrypt or decrypt,

Re: [PATCH 2/2] md: dm-crypt: Optimize the dm-crypt for XTS mode

On 12/14/2015 09:23 AM, Baolin Wang wrote: > In now dm-crypt code, it is ineffective to map one bio with just only > one scatterlist at one time for XTS mode. We can use multiple scatterlists > to map the whole bio and send all scatterlists of one bio to crypto engine > to encrypt or decrypt,

Re: [PATCH v2 0/2] dm verity: add support for error correction

On 12/07/2015 05:31 PM, Sami Tolvanen wrote: > On Mon, Dec 07, 2015 at 09:58:14AM -0500, Mike Snitzer wrote: >> Great. Moving forward it'd be awesome if you could work to get your >> verity FEC support regression tests into cryptsetup's tests. > > Sure. These tests would basically involve

Re: [PATCH v2 0/2] dm verity: add support for error correction

On 12/07/2015 05:31 PM, Sami Tolvanen wrote: > On Mon, Dec 07, 2015 at 09:58:14AM -0500, Mike Snitzer wrote: >> Great. Moving forward it'd be awesome if you could work to get your >> verity FEC support regression tests into cryptsetup's tests. > > Sure. These tests would basically involve

Re: [PATCH 0/4] dm verity: add support for error correction

On 11/09/2015 08:19 PM, Sami Tolvanen wrote: ... > We don't see actual I/O errors very often. Most corruption we've seen > is caused by flaky hardware that doesn't return errors. However, I can > certainly change to code to attempt recovery in this case too. So if I understand it correctly, there

Re: [PATCH 0/4] dm verity: add support for error correction

On 11/09/2015 08:19 PM, Sami Tolvanen wrote: ... > We don't see actual I/O errors very often. Most corruption we've seen > is caused by flaky hardware that doesn't return errors. However, I can > certainly change to code to attempt recovery in this case too. So if I understand it correctly, there

Re: [PATCH 0/4] dm verity: add support for error correction

On 11/05/2015 03:02 AM, Sami Tolvanen wrote: > This patch set adds error correction support to dm-verity, which > makes it possible to recover from data corruption in exchange of > increased space overhead. > > The feature is implemented as part of dm-verity to take advantage > of the existing

Re: [PATCH 0/4] dm verity: add support for error correction

On 11/05/2015 03:02 AM, Sami Tolvanen wrote: > This patch set adds error correction support to dm-verity, which > makes it possible to recover from data corruption in exchange of > increased space overhead. > > The feature is implemented as part of dm-verity to take advantage > of the existing

Re: [PATCH] dm-crypt: never use write same (was Re: [v3.7 Regression] [SCSI] sd: Implement support for WRITE SAME)

(sorry, resending again, not sure if it was sent correctly) On 07/13/2015 06:33 PM, Joseph Salisbury wrote: > Hi Milan, > > The Ubuntu kernel has been carrying this patch since the discussion[0] > we were having about the bug. I don't see that patch was ever included > in mainline. Do you

Re: [PATCH] dm-crypt: never use write same (was Re: [v3.7 Regression] [SCSI] sd: Implement support for WRITE SAME)

On 07/13/2015 06:33 PM, Joseph Salisbury wrote: > Hi Milan, > > The Ubuntu kernel has been carrying this patch since the discussion[0] > we were having about the bug. I don't see that patch was ever included > in mainline. Do you happen to know if this patch is still needed or was > the bug we

  1   2   3   >