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
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) / mun
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
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.
>>
>>
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 a
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
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 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 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 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
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
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:
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
: 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
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
o 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
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 o
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
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 your
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 va
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
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, basicall
g, 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.
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
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
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
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---
>> + T
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
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/07/2017 12:47 PM, Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
...
> Tests with dd [direct i/o]
>
> Sequent
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 inv
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 big
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
>
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,
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 manua
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 performance
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 possibl
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:
>&
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
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
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
f 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 discussion occured, primarily with Milan Broz, which
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.12.
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 thoug
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 ciph
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
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
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
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 -
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 sen
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 encrypt
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
>>> + * scatt
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, which
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 generat
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
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 has
(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 happe
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 w
On 05/05/2015 05:22 AM, Mike Snitzer wrote:
> On Mon, May 04 2015 at 5:32pm -0400,
> Rabin Vincent wrote:
>
>> On Sat, May 02, 2015 at 09:03:28PM +0200, Greg Kroah-Hartman wrote:
>>> 3.14-stable review patch. If anyone has any objections, please let me know.
>>>
>>> --
>>>
>>> F
On 11/30/2014 06:03 PM, Julia Lawall wrote:
> From: Julia Lawall
>
> Memset on a local variable may be removed when it is called just before the
> variable goes out of scope. Using memzero_explicit defeats this
> optimization. A simplified version of the semantic patch that makes this
> change
On 09/06/2014 01:02 AM, beh...@converseincode.com wrote:
> From: Jan-Simon Möller
>
> The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
> precludes the use of compilers which don't implement VLAIS (for instance the
> Clang compiler). This patch instead allocates the ap
On 08/31/2014 01:14 AM, Douglas Gilbert wrote:
> On 14-08-30 04:56 PM, Milan Broz wrote:
>> Hi,
>>
>> I am using scsi_debug in cryptsetup testsuite and with recent 3.17-rc kernel
>> it deadlocks on rmmod of scsi_debug module.
>>
>> For me even this simple rep
Hi,
I am using scsi_debug in cryptsetup testsuite and with recent 3.17-rc kernel
it deadlocks on rmmod of scsi_debug module.
For me even this simple reproducer causes deadlock:
modprobe scsi_debug dev_size_mb=16 sector_size=512 num_tgts=1
DEV="/dev/"$(grep -l -e scsi_debug /sys/block/*/device
On 08/20/2014 03:25 PM, Jussi Kivilinna wrote:
>> One to four GB per second for XTS? 12 GB per second for AES CBC? Somehow
>> that
>> does not sound right.
>
> Agreed, those do not look correct... I wonder what happened there. On
> new run, I got more sane results:
Which cryptsetup version are
On 25.4.2013 15:25, Andi Kleen wrote:
>> Util-linux 2.23 Release Notes
>> =
>>
>> The cryptoloop support in the commands mount(8) and losetup(8) has been
>> REMOVED. The encryption= mount option and -e,-E,--encryption losetup options
>> are no more supported.
>
> That's
On 04/14/2013 06:12 PM, Milan Broz wrote:
> When user requests encryption (or decryption) of block which
> is not aligned to cipher block size through userspace crypto
> interface, an OOps like this can happen
And this is a reproducer for the problem above...
Milan
/*
* Check for
/0x90
[ 112.742578] [] sysenter_do_call+0x12/0x32
Patch fixes it by simply rejecting buffer which is not multiple of cipher block.
(Bug is present in all stable kernels as well.)
Signed-off-by: Milan Broz
---
crypto/algif_skcipher.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
On 12.4.2013 2:22, Tejun Heo wrote:
> On Thu, Apr 11, 2013 at 08:06:10PM -0400, Mikulas Patocka wrote:
>> All that I can tell you is that adding an empty atomic operation
>> "cmpxchg(&bio->bi_css->refcnt, bio->bi_css->refcnt, bio->bi_css->refcnt);"
>> to bio_clone_context and bio_disassociate_tas
On 9.4.2013 20:08, Mikulas Patocka wrote:
>
>
> On Tue, 26 Mar 2013, Milan Broz wrote:
>
>> - Are we sure we are not inroducing some another side channel in disc
>> encryption? (Unprivileged user can measure timing here).
>> (Perhaps stupid reason but pleas
On 26.3.2013 21:28, Mike Snitzer wrote:
On Tue, Mar 26 2013 at 4:05pm -0400,
Milan Broz wrote:
On Mon, Mar 25, 2013 at 11:47:22PM -0400, Mikulas Patocka wrote:
For best performance we could use the unbound workqueue implementation
with request sorting, if people don't object to the re
On 26.3.2013 13:27, Alasdair G Kergon wrote:
[Adding dm-crypt + linux-kernel]
Thanks.
On Mon, Mar 25, 2013 at 11:47:22PM -0400, Mikulas Patocka wrote:
I performed some dm-crypt performance tests as Mike suggested.
It turns out that unbound workqueue performance has improved somewhere
betwe
On 12/19/2012 11:20 PM, Joseph Salisbury wrote:
> Great work, Milan. Your patch fixes the bug, stops the panic and allows
> dm-crypt to function properly.
Thanks.
>
> Will you be requesting this in v3.8 ?
This should go into 3.7 stable as well, I am talking with Alasdair already
how to handle
Does this help?
dm-crypt: never use write same
Ciphertext device is not compatible with WRITE SAME,
disable it for all dmcrypt devices.
Signed-off-by: Milan Broz
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1844,6 +1844,12 @@ static int crypt_iterate_devices(struct dm_target
On 12/19/2012 08:58 PM, Mike Snitzer wrote:
> On Wed, Dec 19 2012 at 11:58am -0500,
> Martin K. Petersen wrote:
>
>>> "Joseph" == Joseph Salisbury writes:
>>
>> Joseph> I captured the netconsole output from boot until I reproduced
>> Joseph> the bug. The RIP points to kcryptd_crypt_write_io_
ithout some manual tweaking, so quite serious problem.)
Anyway, it works now with your patch, so
Reported-and-tested-by: Milan Broz
Thanks,
Milan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi Linus,
seems this commit in 3.7-rc8 caused regression for O_DIRECT
read near the end of the device.
bbec0270bdd887f96377065ee38b8848b5afa395 is the first bad commit
commit bbec0270bdd887f96377065ee38b8848b5afa395
Author: Linus Torvalds
Date: Thu Nov 29 12:31:52 2012 -0800
blkdev_max_bl
On 11/01/2012 09:11 PM, Milan Broz wrote:
> Dm-crypt/cryptsetup provides replacement for long time already.
Just one addition, here are notes how to replace cryptoloop
with cryptsetup.
Because there are several incompatible lostup implementations,
it cannot be automated. But you can easily f
d and remove it completely.
Signed-off-by: Milan Broz
---
drivers/block/Makefile |1 -
drivers/block/cryptoloop.c | 216
2 files changed, 217 deletions(-)
delete mode 100644 drivers/block/cryptoloop.c
diff --git a/drivers/block/Makefile b/dr
encryption is requested.
Signed-off-by: Milan Broz
---
drivers/block/loop.c | 344 +-
include/linux/loop.h | 31 -
2 files changed, 35 insertions(+), 340 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 54046e
Mark encryption loop fields in userspace API deprecated.
Signed-off-by: Milan Broz
---
include/uapi/linux/loop.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/uapi/linux/loop.h b/include/uapi/linux/loop.h
index e0cecd2..d0896c7 100644
--- a
Remove use of CONFIG_BLK_DEV_CRYPTOLOOP across the tree.
Signed-off-by: Milan Broz
---
arch/arm/configs/colibri_pxa270_defconfig |1 -
arch/arm/configs/ezx_defconfig |1 -
arch/arm/configs/imote2_defconfig |1 -
arch/arm/configs/lpc32xx_defconfig
requires device-mapper modules (dm_mod,
dm_crypt).
Alternative (out of tree) loop-AES already replaces most of the kernel
and userpsace code by own patches anyway.
I am not fan of removing old code this way but I do not see alternative here.
Please comment if you see better solution...
Thanks,
Mi
core_initcall().
This patch removes crypto_chain init from algapi initialization,
because this function is called later and already initialized
cryptomgr notifier is lost.
This cause a failure in initialization of larval algorithms,
like e.g. cbc(aes).
Signed-off-by: Milan Broz
--- crypto
On 10/30/2012 10:40 AM, Uwe Kleine-König wrote:
>> Ha, this is exciting, vanilla 3.6.4 works, with -rt10 patch it does not.
> I experienced that problem, too. This is on a laptop with encrypted
> rootfs, so debugging is a bit harder here. I am just setting up another
> machine to debug that.
FYI t
On 10/29/2012 09:14 PM, Tvrtko Ursulin wrote:
> Unless RT patchset is the culprit. Hm.. that would be unexpected, but I
> guess it is worth a shot. I'll let you know what happens without -rt.
Yes, try not patched mainline first.
Focus on the crypto api - if the crypto modules are not loading auto
On 10/29/2012 08:31 PM, Tvrtko Ursulin wrote:
> Just tried 3.6.4 and it is still broken. Is there anything else I could
> try to debug this?
See response from response from Ondra on dmcrypt list - your kernel config
is perhaps broken.
Please use fresh checkout, run make oldconfig and try again.
On 10/21/2012 02:36 PM, Tvrtko Ursulin wrote:
> On 21/10/12 13:20, Zdenek Kaspar wrote:
I would say you are still missing some modules.
> Kernel says this:
> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to
On 10/20/2012 10:44 PM, Tvrtko Ursulin wrote:
> But I repeat, even if I load the required modules before hand things do
> not work.
I would say you are still missing some modules.
> Kernel says this:
> device-mapper: table: 252:1: crypt: Error allocating crypto tfm
> device-mapper: ioctl: er
On 10/12/2012 09:37 PM, Michael Zugelder wrote:
> I'm having an issue reading data via dm-crypt when there is heavy
> writeback going on (i.e. copying large files or using dd). A single
> read takes anywhere from a few seconds to multiple minutes.
>
> Testing setup:
> * Fedora 17, stock 3.5.4-2.f
On 09/24/2012 06:20 PM, Kasatkin, Dmitry wrote:
>> So it can provide confidentiality but it CANNOT provide integrity protection.
>>
> Yes, it provides confidentiality and via encryption it provides
> certain level of integrity protection.
> Data cannot be modified without being detected.
> Decryp
On 09/24/2012 11:55 AM, Dmitry Kasatkin wrote:
> Both dm-verity and dm-crypt provide block level integrity protection.
This is not correct. dm-crypt is transparent block encryption target,
where always size of plaintext == size of ciphertext.
So it can provide confidentiality but it CANNOT provid
On 08/09/2012 02:40 AM, Wesley Miaw wrote:
> On Aug 8, 2012, at 1:56 PM, Milan Broz wrote:
>
>> On 08/08/2012 10:46 PM, Wesley Miaw wrote:
>>
>>> I did modify veritysetup on my own so the format and verify
>>> commands will work with regular files on disk in
On 08/08/2012 10:46 PM, Wesley Miaw wrote:
> On Aug 8, 2012, at 1:31 PM, Milan Broz wrote:
> I did modify veritysetup on my own so the format and verify commands will
> work with regular files on disk instead of having to mount through loop
> devices.
Which veritysetup? In upstream
On 08/08/2012 08:46 PM, Mikulas Patocka wrote:
> The problem with the patch is that it changes interface to the userspace
> tool. The userspace tool veritysetup already exists in recent cryptsetup
> package, so we can't change the interface - you should change the patch so
> that the starting d
Herbert Xu wrote:
> On Wed, Feb 20, 2008 at 12:23:21PM +0100, Milan Broz wrote:
>> It seems that some module dependency was lost,
>> dm-crypt with async crypto depends now on crypto_blkcipher module
>> for this configuration.
>>
>> Herbert, any following change re
Michael S. Tsirkin wrote:
> I am booting a thinkpad T60p off of an encrypted disk (with crypto
> modules in initramfs).
> This works fine in 2.6.24, but in both 2.6.25-rc1 and 2.6.25-rc2
> won't boot with the following messages on the console
> (copied by hand, sorry about typos):
> device-
Christoph Anton Mitterer wrote:
> On Sun, 2008-02-03 at 23:06 +0100, Milan Broz wrote:
...
>>> 2) The second bug happens only rarely and leads to a panic.
>>> Unfortunately it's difficult to reproduce, but it always happened when I
>>> mkfs.ext3 on the /dev/map
Christoph Anton Mitterer wrote:
> ok but this is just, because those files are still cached in RAM>
>
>
>
> Here's the first problem:
> 1) When I now diff the two versions again (the unencrypted and the one
> from the encrypted partition) I get differences...
> I'm quite sure that this is not d
Torsten Kaiser wrote:
> On Nov 19, 2007 10:00 PM, Milan Broz <[EMAIL PROTECTED]> wrote:
>> Torsten Kaiser wrote:
>>> Anything I could try, apart from more boots with slub_debug=F?
>
> One time it triggered with slub_debug=F, but no additional output.
> With slub_
Torsten Kaiser wrote:
> On Nov 19, 2007 8:56 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>> * Torsten Kaiser <[EMAIL PROTECTED]> wrote:
...
> Above this acquire/release sequence is the following comment:
> #ifdef CONFIG_LOCKDEP
> /*
> * It is permissible to free the
1 - 100 of 112 matches
Mail list logo
