ci/archive/20230603/202306031511.xieq4bqz-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202306031511.xieq4bqz-...@intel.com/
cocci warn
On 6/2/23 23:34, Eric Biggers wrote:
On Thu, Jun 01, 2023 at 03:24:39PM +0800, Coiby Xu wrote:
[PATCH 0/5] Support kdump with LUKS encryption by reusing LUKS volume key
The kernel has no concept of LUKS at all. It provides dm-crypt, which LUKS
happens to use. But LUKS is a userspace concept.
Apologies for my inexperience here, but is this patch likely to get
included? I see there's been no discussion.
On Mon, May 29, 2023 at 5:20 PM Russell Harmon wrote:
>
> Documents the meaning of the "buffer", adds documentation of the current
> defaults, and provides an example of how the tunable
On 5/31/23 17:49, Martin Wilck wrote:
On Wed, 2023-05-31 at 15:57 +0200, Xose Vazquez Perez wrote:
ALUA is needed by Hitachi Global-Active Device (GAD):
https://knowledge.hitachivantara.com/Documents/Management_Software/SVOS/8.1/Global-Active_Device/Overview_of_global-active_device
Thanks, b
.com
> patch subject: [PATCH 4/6] device-mapper: Avoid double-fetch of version
> config: x86_64-randconfig-c032-20230531
> (https://download.01.org/0day-ci/archive/20230603/202306031511.xieq4bqz-...@intel.com/config)
> compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
>
> If you fix th
This series contains several miscellaneous fixes to input validation in
device-mapper. The only potentially controversial commits should be the
last two, which prevent creating devices named ".", "..", or "control".
The other patches fix input validation problems that have existed since
at least t
Especially on 32-bit systems, it is possible for the pointer arithmetic
to overflow and cause a userspace pointer to be dereferenced in the
kernel.
Signed-off-by: Demi Marie Obenour
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
---
drivers/md/dm-ioctl.c | 19 +++
Otherwise subsequent code will dereference a misaligned
`struct dm_target_spec *`, which is undefined behavior.
Signed-off-by: Demi Marie Obenour
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: sta...@vger.kernel.org
---
drivers/md/dm-ioctl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
The NUL terminator for each target parameter string must precede the
following 'struct dm_target_spec'. Otherwise, dm_split_args() might
corrupt this struct. Furthermore, the first 'struct dm_target_spec'
must come after the 'struct dm_ioctl', as if it overlaps too much
dm_split_args() could corr
The version is fetched once in check_version(), which then does some
validation and then overwrites the version in userspace with the API
version supported by the kernel. copy_params() then fetches the version
from userspace *again*, and this time no validation is done. The result
is that the ker
Typical userspace setups create a symlink under /dev/mapper with the
name of the device, but /dev/mapper/control is reserved for the control
device. Therefore, trying to create such a device is almost certain to
be a userspace bug.
Signed-off-by: Demi Marie Obenour
---
drivers/md/dm-ioctl.c | 7
Using either of these is going to greatly confuse userspace, as they are
not valid symlink names and so creating the usual /dev/mapper/NAME
symlink will not be possible. As creating a device with either of these
names is almost certainly a userspace bug, just error out.
Signed-off-by: Demi Marie
Key Locker introduces a CPU-internal wrapping key to encode a user key
to a key handle. Then a key handle is referenced instead of the plain
text key.
LOADIWKEY loads a wrapping key in the software-inaccessible CPU state.
It operates only in kernel mode.
The kernel will use this to load a new key
Hi all,
Posting V8 here, a brief status of this enabling:
The last two revisions trend to update the crypto code mainly. The
existing AEX-XTS code was improved further before being shared with
the new code. Then, the new implementation was tuned for the AES-XTS
mode which aligns with the claimed
The x86 instruction decoder needs to know these new instructions that
are going to be used in the crypto library as well as the x86 core
code. Add the following:
LOADIWKEY:
Load a CPU-internal wrapping key.
ENCODEKEY128:
Wrap a 128-bit AES key to a key handle.
ENCODEKEY256:
The primary use case for the feature is bare metal dm-crypt. The key
needs to be restored properly on wakeup, as dm-crypt does not prompt
for the key on resume from suspend. Even if the prompt performs for
unlocking the volume, where the hibernation image is stored, it still
expects to reuse the ke
Every field in struct aesni_xts_ctx is a pointer to a byte array. Each
array has a size of struct crypto_aes_ctx. Then, the field can be
redefined as that struct type instead of the obscure pointer.
Subsequently, the address to struct aesni_xts_ctx should be aligned
right away rather than on every
Key Locker is a CPU feature to reduce key exfiltration opportunities.
It converts the AES key into an encoded form, called 'key handle', to
reduce the exposure of private key material in memory.
This key conversion as well as all subsequent data transformation are
provided by new AES instructions
Key Locker's AES instruction set ('AES-KL') has a similar programming
interface to AES-NI. The internal ABI in the assembly code will have
the same prototype as AES-NI. Then, the glue code will be the same as
AES-NI's.
The new AES code will support the XTS mode alone as disk encryption is
the only
Key Locker is a CPU feature to minimize exposure of clear-text key
material. An encoded form, called 'key handle', is referenced for data
encryption or decryption instead of accessing the clear text key.
A wrapping key loaded in the CPU's software-inaccessible state is used
to transform a user key
The CPU state that contains the wrapping key is in the same power
domain as the cache. So any sleep state that would invalidate the
cache (like S3) also invalidates the state of the wrapping key.
But, since the state is inaccessible to software, it needs a special
mechanism to save and restore the
Both Key Locker enabling code in the x86 core and AES Key Locker code
in the crypto library will need to reference some CPUID bits. Define
these feature-specific CPUID leaf and bits.
Signed-off-by: Chang S. Bae
Reviewed-by: Dan Williams
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
The wrapping key is an entity to encode a clear text key into a key
handle. This key is a pivot in protecting user keys. So the value has
to be randomized before being loaded in the software-invisible CPU
state.
The wrapping key needs to be established before the first user. Given
that the only pr
Add CONFIG_X86_KEYLOCKER to gate whether Key Locker is initialized at
boot. The option is selected by the Key Locker cipher module
CRYPTO_AES_KL (to be added in a later patch).
Add a new command line option "nokeylocker" to optionally override the
default CONFIG_X86_KEYLOCKER=y behavior.
Signed-o
Document the overview of the feature along with relevant consideration
when provisioning dm-crypt volumes with AES-KL instead of AES-NI.
Signed-off-by: Chang S. Bae
Reviewed-by: Dan Williams
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: "H. Peter Anvin"
Cc: Jon
On Fri, Jun 02 2023 at 8:52P -0400,
Dave Chinner wrote:
> On Fri, Jun 02, 2023 at 11:44:27AM -0700, Sarthak Kukreti wrote:
> > On Tue, May 30, 2023 at 8:28 AM Mike Snitzer wrote:
> > >
> > > On Tue, May 30 2023 at 10:55P -0400,
> > > Joe Thornber wrote:
> > >
> > > > On Tue, May 30, 2023 at 3:
On Sat, Jun 03, 2023 at 08:22:24AM -0700, Chang S. Bae wrote:
> +static __init int x86_nokeylocker_setup(char *arg)
> +{
> + /* Expect an exact match without trailing characters. */
> + if (strlen(arg))
> + return 0;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER))
>
Signed-off-by: Russell Harmon
---
Documentation/admin-guide/device-mapper/dm-integrity.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst
b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 8db172efa272..b
Thanks for taking a look. Here's the multi-patch series plus the changes
you suggested.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Signed-off-by: Russell Harmon
---
.../admin-guide/device-mapper/dm-integrity.rst | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst
b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index b2a698
Signed-off-by: Russell Harmon
---
.../device-mapper/dm-integrity.rst| 22 +--
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst
b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 31f5
Signed-off-by: Russell Harmon
---
Documentation/admin-guide/device-mapper/dm-integrity.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/admin-guide/device-mapper/dm-integrity.rst
b/Documentation/admin-guide/device-mapper/dm-integrity.rst
index 0241457c0027..d8a5f14d0e3
32 matches
Mail list logo
