On 2/6/2025 8:49 AM, Mimi Zohar wrote:
Thanks, Steven, for picking up and working on Tushar's patch set.
I normally finish reviewing the patch set, before commenting. In this case,
there's
a generic comment that relates to all of the patches. It's also a way of
letting you
know that I've sta
On 2/7/2025 11:10 AM, Mimi Zohar wrote:
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
Carrying the IMA measurement list across kexec requires allocating a
buffer and copying the measurement records. Separate allocating the
buffer and copying the measurement records into separate functio
On 2/4/2025 11:39 AM, Stefan Berger wrote:
On 2/3/25 6:20 PM, steven chen wrote:
kexec_calculate_store_digests() calculates and stores the digest of the
segment at kexec_file_load syscall where the IMA segment is also
allocated. With this series, the IMA segment will be updated with the
measure
On Thu, 2025-02-06 at 11:49 -0500, Mimi Zohar wrote:
> Thanks, Steven, for picking up and working on Tushar's patch set.
>
> I normally finish reviewing the patch set, before commenting. In this case,
> there's
> a generic comment that relates to all of the patches. It's also a way of
> letting
On 2/7/25 12:06 PM, Mimi Zohar wrote:
On Fri, 2025-02-07 at 10:16 -0500, Mimi Zohar wrote:
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
The amount of memory allocated at kexec load, even with the extra memory
allocated, might not be large enough for the entire measurement list. The
On Mon, 2025-02-03 at 16:56 -0800, steven chen wrote:
> On 2/3/2025 4:50 PM, Mimi Zohar wrote:
> > On Mon, 2025-02-03 at 15:25 -0800, steven chen wrote:
> > > Hi all,
> > >
> > > The below is the correct version for review.
> > >
> > > [PATCH v7 0/7] ima: kexec: measure events between kexec load
Hi Steven,
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
> Currently, the mechanism to map and unmap segments to the kimage
> structure is not available to the subsystems outside of kexec. This
> functionality is needed when IMA is allocating the memory segments
> during kexec 'load' oper
On 2/7/2025 9:48 AM, Stefan Berger wrote:
On 2/7/25 12:06 PM, Mimi Zohar wrote:
On Fri, 2025-02-07 at 10:16 -0500, Mimi Zohar wrote:
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
The amount of memory allocated at kexec load, even with the extra
memory
allocated, might not be large en
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
> Carrying the IMA measurement list across kexec requires allocating a
> buffer and copying the measurement records. Separate allocating the
> buffer and copying the measurement records into separate functions in
> order to allocate the buffer
On Thu, Feb 06, 2025 at 08:50:30PM -0800, Andrew Morton wrote:
> My x86_64 allmodconfig sayeth:
>
> WARNING: modpost: vmlinux: section mismatch in reference:
> kho_reserve_scratch+0xca (section: .text) -> memblock_alloc_try_nid (section:
> .init.text)
> WARNING: modpost: vmlinux: section mismatc
On Thu, Feb 06, 2025 at 04:29:39PM -0800, Andrew Morton wrote:
> On Thu, 6 Feb 2025 15:27:40 +0200 Mike Rapoport wrote:
>
> > This a next version of Alex's "kexec: Allow preservation of ftrace buffers"
> > series (https://lore.kernel.org/all/20240117144704.602-1-g...@amazon.com),
> > just to mak
When the kdump kernel image and initrd are loaded, the dm crypts keys
will be read from keyring and then stored in kdump reserved memory.
Assume a key won't exceed 256 bytes thus MAX_KEY_SIZE=256 according to
"cryptsetup benchmark".
Signed-off-by: Coiby Xu
---
include/linux/crash_core.h | 6
A configfs /sys/kernel/config/crash_dm_crypt_keys is provided for user
space to make the dm crypt keys persist for the kdump kernel. Take the
case of dumping to a LUKS-encrypted target as an example, here is the
life cycle of the kdump copies of LUKS volume keys,
1. After the 1st kernel loads the
Crash kernel will retrieve the dm crypt keys based on the dmcryptkeys
command line parameter. When user space writes the key description to
/sys/kernel/config/crash_dm_crypt_key/restore, the crash kernel will
save the encryption keys to the user keyring. Then user space e.g.
cryptsetup's --volume-k
Currently, kexec_buf is placed in order which means for the same
machine, the info in the kexec_buf is always located at the same
position each time the machine is booted. This may cause a risk for
sensitive information like LUKS volume key. Now struct kexec_buf has a
new field random which indicat
When there are CPU and memory hot un/plugs, the dm crypt keys may need
to be reloaded again depending on the solution for crash hotplug
support. Currently, there are two solutions. One is to utilizes udev to
instruct user space to reload the kdump kernel image and initrd,
elfcorehdr and etc again.
1st kernel will build up the kernel command parameter dmcryptkeys as
similar to elfcorehdr to pass the memory address of the stored info of
dm crypt key to kdump kernel.
Signed-off-by: Coiby Xu
---
Documentation/admin-guide/kdump/kdump.rst | 4 ++--
arch/x86/kernel/crash.c | 2
LUKS is the standard for Linux disk encryption, widely adopted by users,
and in some cases, such as Confidential VMs, it is a requirement. With
kdump enabled, when the first kernel crashes, the system can boot into
the kdump/crash kernel to dump the memory image (i.e., /proc/vmcore)
to a specifie
This adds an addition layer of protection for the saved copy of dm
crypt key. Trying to access the saved copy will cause page fault.
Suggested-by: Pingfan Liu
Signed-off-by: Coiby Xu
---
arch/x86/kernel/machine_kexec_64.c | 22 ++
1 file changed, 22 insertions(+)
diff --git
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
> The amount of memory allocated at kexec load, even with the extra memory
> allocated, might not be large enough for the entire measurement list. The
> indeterminate interval between kexec 'load' and 'execute' could exacerbate
> this problem.
Hi Steven,
On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
> The extra memory allocated for carrying the IMA measurement list across
> kexec is hard-coded as half a PAGE. Make it configurable.
>
> Define a Kconfig option, IMA_KEXEC_EXTRA_MEMORY_KB, to configure the
> extra memory (in kb) t
On Fri, 2025-02-07 at 10:16 -0500, Mimi Zohar wrote:
> On Mon, 2025-02-03 at 15:20 -0800, steven chen wrote:
> > The amount of memory allocated at kexec load, even with the extra memory
> > allocated, might not be large enough for the entire measurement list. The
> > indeterminate interval between
22 matches
Mail list logo
