Hi,
I've hit a dm-integrity crash when re-extending dm-integrity device. The
trick is that underlying device needs to change its size as well.
There's reproducer attached which I have tested on top of scsi_debug
device but it's not limited to scsi_debug.
Tested kernel version: 5.17.0, My min
On 4/20/20 12:13 PM, Paul Wise wrote:
On Mon, 2020-04-20 at 09:35 +0200, Ondrej Kozina wrote:
Did you have discard allowed on both dm-crypt devices? dm-crypt
(kernel) does not allow discards by default.
I did not, I guess that explains why I got no errors.
FYI if you use LUKS2 metadata
On 4/19/20 4:48 PM, Paul Wise wrote:
On Sun, 2020-04-19 at 09:19 -0400, Mike Snitzer wrote:
You went overboard with implementation before checking to see if your
work would be well received. Your 2/3 patch header shows you're
capable of analyzing past commits to explain the evolution of code,
On 10/12/2018 01:56 PM, laurent cop wrote:
Hello,
I have trouble while in top of the stack :
mkfs.ext4 /dev/mapper/raid0luks2
/dev/mapper/raid0luks2 alignement is offset by 147456 bytes
This may result in very poor performance (re-) partitioning is suggested.
I have the same pb with mkfs.xfs
I
the kernel
key retention service")
Signed-off-by: Ondrej Kozina
---
drivers/md/dm-crypt.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 9fc12f5..334b0a3 100644
--- a/drivers/md/dm-crypt.c
+++ b/driver
t.
Mike, If you accept the patch please resend also to stable kernels.
[1]
https://gitlab.com/cryptsetup/cryptsetup/blob/wip-luks2/tests/keyring-compat-test
Ondrej Kozina (1):
dm crypt: wipe kernel key copy after IV initialization
drivers/md/dm-crypt.c | 12
1 file changed, 8
On 08/09/2017 03:38 PM, h...@lst.de wrote:
Does commit 615d22a51c04856efe62af6e1d5b450aaf5cc2c0
"block: Fix __blkdev_issue_zeroout loop" fix the issue for you?
I crashed the 4.13-rc4 with the test above (blkdiscard -z on dm-crypt
dev). Unfortunately I hadn't have my VM configured properly so t
On 06/19/2017 04:20 PM, Mike Snitzer wrote:
Looks like submit_flush_bio() is disabling/enabling interrupts from
interrupt context. Ondrej, does this patch fix the issue?
I let it spin for 30 minutes on patched dm-integrity and everything
seems ok now. The moment I loaded back the old one it
same log again, hopefully prettier format. Sorry:
[ 330.980914] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[ 330.980923] [ cut here ]
[ 330.982627] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2748
trace_hardirqs_on_caller+0x107/0x180
[ 330.984340] Modules li
Hi,
cryptsetup testsuite easily triggers following crash. I can provide more
info on demand, but currently most straightforward way to trigger it is:
1) checkout cryptsetup master branch
(https://gitlab.com/cryptsetup/cryptsetup.git)
2)./autogen.sh --disable-python --enable-integritysetup
3)
message "key wipe" used to wipe real key stored in crypto layer by rewriting it
with zeroes. This no longer works in FIPS mode for xts. With commit 28856a9
while running in FIPS mode the crypto key part has to differ from tweak one.
Signed-off-by: Ondrej Kozina
---
drivers/md/dm-c
56 (dm crypt: add ability to use keys from the kernel key
retention service)
Signed-off-by: Ondrej Kozina
---
drivers/md/dm-crypt.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 7c6c572..8a9f742 100644
--- a/drivers/md
87c R14: 7fff38c097ec R15:
Reported-by: Milan Broz
Fixes: c538f6ec9f56 (dm crypt: add ability to use keys from the kernel key
retention service)
Signed-off-by: Ondrej Kozina
---
drivers/md/dm-crypt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dri
Well, I was wrong. Unfortunately key_string may theoreticaly contain
whitespace even after it's processed by dm_split_args(). The dm core
driver supports escaping of almost all chars including any whitespace.
if uspace passes key in the kernel in format ":32:logon:my_prefix:my\ key"
the dm-crypt w
Hi Mike,
those are fixes for latest version (including your cleanup patch). I've fixed
one
awkward bug the rest is based on David's sugestions he gave me earlier today.
David, may I also kindly ask you for oficial 'Reviewed-by' stamp provided
it's correct now (with regard to kernel keyring bits
representation may be
replaced with key passed in key_string format and vice versa.
(Patch is based on original work by Andrey Ryabinin)
Signed-off-by: Ondrej Kozina
---
Documentation/device-mapper/dm-crypt.txt | 25 -
drivers/md/dm-crypt.c| 169 +
On 11/17/2016 09:06 PM, Ondrej Kozina wrote:
On 11/17/2016 05:35 PM, Andrey Ryabinin wrote:
On 11/16/2016 11:47 PM, Ondrej Kozina wrote:
(Please still consider it to be RFC only, I need to modify the uspace teststuite
again due to changes in key_string format. Also the changes to dm-crypt
On 11/17/2016 05:35 PM, Andrey Ryabinin wrote:
On 11/16/2016 11:47 PM, Ondrej Kozina wrote:
(Please still consider it to be RFC only, I need to modify the uspace teststuite
again due to changes in key_string format. Also the changes to dm-crypt
documentation
will follow before final submit
vice initialised with a key passed in hex representation may be
replaced with key passed in key_string format and vice versa.
(Patch is based on original work by Andrey Ryabinin)
Signed-off-by: Ondrej Kozina
---
drivers/md/dm-crypt.c | 167 --
1 file
From: Andrey Ryabinin
(original patch rebased on top of previous one by Ondrej Kozina)
The kernel key service is a generic way to store keys for the use of
other subsystems. Currently there is no way to use kernel keys in dm-crypt.
This patch aims to fix that. Instead of key userspace may pass
1) if we load kernel keyring key referenced by key description we
should also return same key description via later status call. First
the table should remain the same, second it's not reasonable to expose
kernel key payload that could already have been be invalidated/expired
by kernel keyring API.
(just for reference. the patch's been already posted on dm-devel)
on crypt_message() key set code path while loading new key
replacing the old one in case tfm->setkey() fails
we would end having invalid key in crypto layer but
DM_CRYPT_KEY_VALID flag set.
Signed-off-by: Ondre
key erasure on table
destruction (even when
provided only via optional parameter) it will require to patch kernel keyring
service so let's postpone it after we get those changes in upstream kernel.
Andrey Ryabinin (1):
dm-crypt: add ability to use keys from the kernel key retention
service
Ondr
on crypt_message() key set code path while loading new key
replacing the old one in case tfm->setkey() fails
we would end having invalid key in crypto layer but
DM_CRYPT_KEY_VALID flag set.
Signed-off-by: Ondrej Kozina
---
drivers/md/dm-crypt.c | 7 +--
1 file changed, 5 insertions(+)
On 08/09/2016 03:56 PM, Andrey Ryabinin wrote:
Hi Andrey,
I'm definitely in favour of dm-crypt with support for kernel keyring
service, but I think this patch do lack in addressing few issues:
Currently the dm-crypt guarantees that on remove ioctl command the
volume key gets deleted from bot
On 07/14/2016 05:31 PM, Michal Hocko wrote:
On Thu 14-07-16 16:08:28, Ondrej Kozina wrote:
[...]
As Mikulas pointed out, this doesn't work. The system froze as well with the
patch above. Will try to tweak the patch with Mikulas's suggestion...
Thank you for testing! Do you happ
On 07/14/2016 04:59 PM, Michal Hocko wrote:
On Thu 14-07-16 10:00:16, Mikulas Patocka wrote:
On Thu, 14 Jul 2016, Michal Hocko wrote:
On Wed 13-07-16 11:02:15, Mikulas Patocka wrote:
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 4f3cb3554944..0b806810efab 100644
--- a/d
On 07/14/2016 02:51 PM, Michal Hocko wrote:
On Wed 13-07-16 11:02:15, Mikulas Patocka wrote:
On Wed, 13 Jul 2016, Michal Hocko wrote:
[...]
We are discussing several topics together so let's focus on this
particlar thing for now
The kernel 4.7-rc almost deadlocks in another way. The machine
On 07/13/2016 05:02 PM, Mikulas Patocka wrote:
On Wed, 13 Jul 2016, Michal Hocko wrote:
On Tue 12-07-16 19:44:11, Mikulas Patocka wrote:
The problem of swapping to dm-crypt is this.
The free memory goes low, kswapd decides that some page should be swapped
out. However, when you swap to an e
On 07/13/2016 05:32 PM, Matthias Dahl wrote:
No matter what, I have no clue how to further diagnose this issue. And
given that I already had unsolvable issues with dm-crypt a couple of
months ago with my old machine where the system simply hang itself or
went OOM when the swap was encrypted and
On 04/21/2016 09:48 AM, Matthias Dahl wrote:
Hello @all,
first of all, I sent this exact msg also to the lkml a few days ago but
since I received no reaction, I thought this list might be a better
place for this problem -- or I might at least reach the right persons to
get this fixed/debugged/..
On 04/27/2016 02:44 PM, Matthias Dahl wrote:
Hello @all,
since I haven't seen any replies to this so far, is there anything else
I can do to help track this bug down?
I have posted the original message to both the lkml as well as dm-devel
lists, by the way, without much luck. ;-)
Thanks in adv
32 matches
Mail list logo
