Displaying 12 results from an estimated 12 matches for "d631cb100".
2020 Jan 21
12
[PATCH 0/1] WIP: Support LUKS-encrypted partitions
The following patch attempts to implement sparsification of
LUKS-encrypted partitions. It uses lsblk to pair the underlying LUKS
block device with its mapped name. Also, --allow-discards was added
by default to luks_open().
There are several potential issues that I can think of:
1) If and entire device is encrypted (not just one of more partitions),
the lsblk trick might not work.
2) The
2019 Nov 29
0
[PATCH 1/1] New API: luks_uuid
...f a LUKS device.
---
daemon/luks.c | 25 +++++++++++++++++++++++++
generator/actions_core.ml | 8 ++++++++
generator/proc_nr.ml | 1 +
lib/MAX_PROC_NR | 2 +-
4 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/daemon/luks.c b/daemon/luks.c
index 5c48a91eb..d631cb100 100644
--- a/daemon/luks.c
+++ b/daemon/luks.c
@@ -292,3 +292,28 @@ do_luks_kill_slot (const char *device, const char *key, int keyslot)
return 0;
}
+
+char *
+do_luks_uuid (const char *device)
+{
+ const char *argv[MAX_ARGS];
+ size_t i = 0;
+
+ ADD_ARG (argv, i, "cryptsetup");...
2020 Jan 21
0
[PATCH 1/1] WIP: sparsify: Support LUKS-encrypted partitions
...> None
+ | part -> let mnt = Mountable.of_path @@ "/dev/mapper/" ^ part in
+ Some [mnt, Blkid.vfs_type mnt]
+ )
(* A single btrfs device can turn into many volumes. *)
else if vfs_type = "btrfs" then (
diff --git a/daemon/luks.c b/daemon/luks.c
index d631cb100..1ffeaf293 100644
--- a/daemon/luks.c
+++ b/daemon/luks.c
@@ -110,6 +110,7 @@ luks_open (const char *device, const char *key, const char *mapname,
ADD_ARG (argv, i, "-d");
ADD_ARG (argv, i, tempfile);
if (readonly) ADD_ARG (argv, i, "--readonly");
+ ADD_ARG (argv, i, &...
2020 Jan 27
0
[PATCH v2 2/2] sparsify: support LUKS-encrypted partitions
...ne
+ | part ->
+ let mnt = Mountable.of_path @@ "/dev/mapper/" ^ part in
+ Some [mnt, Blkid.vfs_type mnt]
+ )
(* A single btrfs device can turn into many volumes. *)
else if vfs_type = "btrfs" then (
diff --git a/daemon/luks.c b/daemon/luks.c
index d631cb100..306b2dcfb 100644
--- a/daemon/luks.c
+++ b/daemon/luks.c
@@ -83,7 +83,7 @@ remove_temp (char *tempfile)
static int
luks_open (const char *device, const char *key, const char *mapname,
- int readonly)
+ int readonly, int allowdiscards)
{
/* Sanity check: /dev/mapper/mapn...
2019 Nov 29
8
[PATCH 0/1] Allow UUIDs for --key identifiers.
This combined patch series enables to decrypt LUKS devices on inspection
by allowing the UUID of the LUKS device with the --key syntax.
I opted for reusing the option instead of adding another one, as I think
that device names and UUIDs are different enough that can be properly
distinguished.
A test for this (patch #4) can be applied only when the patches for
common are applied, and the
2020 Jan 22
3
[PATCH 1/1] sparsify: support LUKS-encrypted partitions
...+ | part ->
+ let mnt = Mountable.of_path @@ "/dev/mapper/" ^ part in
+ Some [mnt, Blkid.vfs_type mnt]
+ )
(* A single btrfs device can turn into many volumes. *)
else if vfs_type = "btrfs" then (
diff --git a/daemon/luks.c b/daemon/luks.c
index d631cb100..306b2dcfb 100644
--- a/daemon/luks.c
+++ b/daemon/luks.c
@@ -83,7 +83,7 @@ remove_temp (char *tempfile)
static int
luks_open (const char *device, const char *key, const char *mapname,
- int readonly)
+ int readonly, int allowdiscards)
{
/* Sanity check: /dev/mapper/mapn...
2020 Jan 27
3
[PATCH v2 1/2] mltools, options: support --allow-discards when decrypting LUKS devices
---
mltools/tools_utils-c.c | 8 ++++----
mltools/tools_utils.ml | 6 +++---
mltools/tools_utils.mli | 8 ++++++--
options/decrypt.c | 5 +++--
options/inspect.c | 2 +-
options/options.h | 2 +-
6 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/mltools/tools_utils-c.c b/mltools/tools_utils-c.c
index 6c43b8d..1dcebc4 100644
--- a/mltools/tools_utils-c.c
+++
2020 Mar 30
0
[PATCH 1/7] New APIs: cryptsetup-open and cryptsetup-close.
...* here, but that seems to have only downsides).
+ *)
+let luks_open device key mapname = cryptsetup_open device key mapname
+let luks_open_ro device key mapname =
+ cryptsetup_open ~readonly:true device key mapname
+let luks_close = cryptsetup_close
diff --git a/daemon/luks.c b/daemon/luks.c
index d631cb100..51ced585d 100644
--- a/daemon/luks.c
+++ b/daemon/luks.c
@@ -81,89 +81,6 @@ remove_temp (char *tempfile)
free (tempfile);
}
-static int
-luks_open (const char *device, const char *key, const char *mapname,
- int readonly)
-{
- /* Sanity check: /dev/mapper/mapname must not exist al...
2020 Sep 07
0
[PATCH v2 1/7] New APIs: cryptsetup-open and cryptsetup-close.
...* here, but that seems to have only downsides).
+ *)
+let luks_open device key mapname = cryptsetup_open device key mapname
+let luks_open_ro device key mapname =
+ cryptsetup_open ~readonly:true device key mapname
+let luks_close = cryptsetup_close
diff --git a/daemon/luks.c b/daemon/luks.c
index d631cb100..51ced585d 100644
--- a/daemon/luks.c
+++ b/daemon/luks.c
@@ -81,89 +81,6 @@ remove_temp (char *tempfile)
free (tempfile);
}
-static int
-luks_open (const char *device, const char *key, const char *mapname,
- int readonly)
-{
- /* Sanity check: /dev/mapper/mapname must not exist al...
2020 Sep 07
9
[PATCH v2 0/7] Windows BitLocker support.
Original version linked from here:
https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8
There is no change in the code in this series, but feedback from the
original series was we shouldn't lose the error message in patch 7.
When I tested this just now in fact we don't lose the error if
debugging is enabled, but I have updated the commit message to note
what the error message is in the
2020 Mar 30
9
[PATCH 0/7] Support Windows BitLocker (RHBZ#1808977).
These commits, along with the associated changes to common:
https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html
support the transparent decryption and inspection of Windows guests
encrypted with BitLocker encryption.
To do the BitLocker decryption requires cryptsetup 2.3.0 (although
cryptsetup 2.3 is not required for existing LUKS use). It also
requires a new-ish Linux kernel, I
2020 Sep 17
13
[PATCH v3 0/8] Windows BitLocker support.
As discussed in the emails today, this is the third version addressing
most points from the v1/v2 review.
You will need to pair this with the changes in libguestfs-common from
this series:
https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html
Rich.