Re: [PATCH v2 8/8] crash_core.c: remove unneeded functions

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > So far, nobody calls functions parse_crashkernel_high() and > parse_crashkernel_low(), remove both of them. Reviewed-by: Zhen Lei > > Signed-off-by: Baoquan He > --- > include/linux/crash_core.h | 4 > kernel/crash_core.c| 18

Re: [PATCH v2 7/8] arm64: kdump: use generic interface to simplify crashkernel reservation

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > With the help of newly changed function parse_crashkernel() and > generic reserve_crashkernel_generic(), crashkernel reservation can be > simplified by steps: > > 1) Add a new header file , and define CRASH_ALIGN, >CRASH_ADDR_LOW_MAX,

Re: [PATCH v2 6/8] x86: kdump: use generic interface to simplify crashkernel reservation code

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > With the help of newly changed function parse_crashkernel() and > generic reserve_crashkernel_generic(), crashkernel reservation can be > simplified by steps: > > 1) Add a new header file , and define CRASH_ALIGN, >CRASH_ADDR_LOW_MAX,

Re: [PATCH v2 4/8] crash_core: add generic function to do reservation

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > In architecture like x86_64, arm64 and riscv, they have vast virtual > address space and usually have huge physical memory RAM. Their > crashkernel reservation doesn't have to be limited under 4G RAM, > but can be extended to the whole physical memory via

Re: [PATCH v2 3/8] crash_core: change parse_crashkernel() to support crashkernel=,high|low parsing

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > Now parse_crashkernel() is a real entry point for all kinds of > crahskernel parsing on any architecture. > > And wrap the crahskernel=,high|low handling inside > CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION ifdeffery scope. > > Signed-off-by:

Re: [PATCH v2 2/8] crash_core: change the prototype of function parse_crashkernel()

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > Add two parameters 'low_size' and 'high' to function parse_crashkernel(), > later crashkernel=,high|low parsing will be added. Make adjustments in all > call sites of parse_crashkernel() in arch. Reviewed-by: Zhen Lei > > Signed-off-by: Baoquan He >

Re: [PATCH v2 1/8] crash_core.c: remove unnecessary parameter of function

2023-08-30 Thread Leizhen (ThunderTown)
On 2023/8/29 20:16, Baoquan He wrote: > In all call sites of __parse_crashkernel(), the parameter 'name' is > hardcoded as "crashkernel=". So remove the unnecessary parameter 'name', > add local varibale 'name' inside __parse_crashkernel() instead. Reviewed-by: Zhen Lei > > Signed-off-by:

Re: [RFC PATCH] Introduce persistent memory pool

2023-08-30 Thread Arnd Bergmann
On Wed, Aug 30, 2023, at 03:20, Alexander Graf wrote: > On 30.08.23 00:07, Stanislav Kinsburskii wrote: >> On Mon, Aug 28, 2023 at 10:50:19PM +0200, Alexander Graf wrote: >> Device tree or ACPI are options indeed. However AFAIU in case of DT user >> space has to involved into the picture to

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Paul Moore
On Wed, Aug 30, 2023 at 7:07 PM Mimi Zohar wrote: > On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote: > > On Wed, Aug 30, 2023 at 6:21 PM Paul Moore wrote: > > > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar wrote: > > > > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > > > > > On Wed,

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Mimi Zohar
On Wed, 2023-08-30 at 18:23 -0400, Paul Moore wrote: > On Wed, Aug 30, 2023 at 6:21 PM Paul Moore wrote: > > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar wrote: > > > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > > > > On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar wrote: > > > > > Your

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Paul Moore
On Wed, Aug 30, 2023 at 6:21 PM Paul Moore wrote: > On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar wrote: > > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > > > On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar wrote: > > > > Your initial question was "what happens if the file/filesystem becomes >

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Paul Moore
On Wed, Aug 30, 2023 at 5:50 PM Mimi Zohar wrote: > On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > > On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar wrote: > > > Your initial question was "what happens if the file/filesystem becomes > > > inaccessible at some point and an attestation client

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Mimi Zohar
On Wed, 2023-08-30 at 16:47 -0400, Paul Moore wrote: > On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar wrote: > > Your initial question was "what happens if the file/filesystem becomes > > inaccessible at some point and an attestation client attempts to read > > the entire log?". For what reason

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Paul Moore
On Wed, Aug 30, 2023 at 4:25 PM Mimi Zohar wrote: > Your initial question was "what happens if the file/filesystem becomes > inaccessible at some point and an attestation client attempts to read > the entire log?". For what reason would it be inaccessible? For the > original single tmpfs file,

Re: [RFC] IMA Log Snapshotting Design Proposal

2023-08-30 Thread Mimi Zohar
On Tue, 2023-08-29 at 19:15 -0400, Paul Moore wrote: > On Tue, Aug 29, 2023 at 5:54 PM Mimi Zohar wrote: > > On Tue, 2023-08-29 at 17:30 -0400, Paul Moore wrote: > > > On Tue, Aug 29, 2023 at 5:05 PM Mimi Zohar wrote: > > > > On Tue, 2023-08-29 at 15:34 -0400, Paul Moore wrote: > > > > > On Mon,

Re: [PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread pstanner
On Wed, 2023-08-30 at 17:29 +0300, Andy Shevchenko wrote: > On Wed, Aug 30, 2023 at 5:19 PM wrote: > > On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote: > > > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner > > > > > > wrote: > > > > > --- a/include/linux/string.h > > > > +++

Re: [RFC] IMA Log Snapshotting Design Proposal - unseal

2023-08-30 Thread Ken Goldman
On 8/1/2023 3:12 PM, Sush Shringarputale wrote: For remote attestation to work, the service will need to know how to validate the snapshot_aggregate entry in the IMA log. It will have to read the PCR values present in the template data of snapshot_aggregate event in the latest IMA log, and

Re: [RFC] IMA Log Snapshotting Design Proposal - aggregate

2023-08-30 Thread Ken Goldman
On 8/1/2023 3:12 PM, Sush Shringarputale wrote: - A user-mode process will trigger the snapshot by opening a file in SysFS   say /sys/kernel/security/ima/snapshot (referred to as sysk_ima_snapshot_file   here onwards). - The Kernel will get the current TPM PCR values and PCR update counter

Re: [RFC] IMA Log Snapshotting Design Proposal - network bandwidth

2023-08-30 Thread Ken Goldman
On 8/1/2023 3:12 PM, Sush Shringarputale wrote: In addition, a large IMA log can add pressure on the network bandwidth when the attestation client sends it to remote-attestation-service. I would not worry too much about network bandwidth. 1. Every solution eventually realizes that sending

Re: [PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread Andy Shevchenko
On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner wrote: > + if (unlikely(check_mul_overflow(n, size, ))) > + return ERR_PTR(-EINVAL); > + if (unlikely(check_mul_overflow(n, size, ))) > + return ERR_PTR(-EINVAL); Btw, why not -EOVERFLOW ? -- With Best

Re: [PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread Andy Shevchenko
On Wed, Aug 30, 2023 at 5:19 PM wrote: > On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote: > > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner > > wrote: > > > --- a/include/linux/string.h > > > +++ b/include/linux/string.h > > > > I'm wondering if this has no side-effects as

Re: [PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread pstanner
On Wed, 2023-08-30 at 17:15 +0300, Andy Shevchenko wrote: > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner > wrote: > > > +   if (unlikely(check_mul_overflow(n, size, ))) > > +   return ERR_PTR(-EINVAL); > > > +   if (unlikely(check_mul_overflow(n, size, ))) > > +   

Re: [PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread pstanner
On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote: > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner > wrote: > > > > Currently, user array duplications are sometimes done without an > > overflow check. Sometimes the checks are done manually; sometimes > > the > > array size is calculated

Re: [PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread Andy Shevchenko
On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner wrote: > > Currently, user array duplications are sometimes done without an > overflow check. Sometimes the checks are done manually; sometimes the > array size is calculated with array_size() and sometimes by calculating > n * size directly in

[PATCH 3/5] kernel: watch_queue: copy user-array safely

2023-08-30 Thread Philipp Stanner
Currently, there is no overflow-check with memdup_user(). Use the new function memdup_array_user() instead of memdup_user() for duplicating the user-space array safely. Suggested-by: David Airlie Signed-off-by: Philipp Stanner --- kernel/watch_queue.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 4/5] drm_lease.c: copy user-array safely

2023-08-30 Thread Philipp Stanner
Currently, there is no overflow-check with memdup_user(). Use the new function memdup_array_user() instead of memdup_user() for duplicating the user-space array safely. Suggested-by: David Airlie Signed-off-by: Philipp Stanner --- drivers/gpu/drm/drm_lease.c | 4 ++-- 1 file changed, 2

[PATCH 2/5] kernel: kexec: copy user-array safely

2023-08-30 Thread Philipp Stanner
Currently, there is no overflow-check with memdup_user(). Use the new function memdup_array_user() instead of memdup_user() for duplicating the user-space array safely. Suggested-by: David Airlie Signed-off-by: Philipp Stanner --- kernel/kexec.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 1/5] string.h: add array-wrappers for (v)memdup_user()

2023-08-30 Thread Philipp Stanner
Currently, user array duplications are sometimes done without an overflow check. Sometimes the checks are done manually; sometimes the array size is calculated with array_size() and sometimes by calculating n * size directly in code. Introduce wrappers for arrays for memdup_user() and

[PATCH 5/5] drm: vmgfx_surface.c: copy user-array safely

2023-08-30 Thread Philipp Stanner
Currently, there is no overflow-check with memdup_user(). Use the new function memdup_array_user() instead of memdup_user() for duplicating the user-space array safely. Suggested-by: David Airlie Signed-off-by: Philipp Stanner --- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++-- 1 file

[PATCH 0/5] Introduce new wrappers to copy user-arrays

2023-08-30 Thread Philipp Stanner
Hi! David Airlie suggested that we could implement new wrappers around (v)memdup_user() for duplicating user arrays. This small patch series first implements the two new wrapper functions memdup_array_user() and vmemdup_array_user(). They calculate the array-sizes safely, i.e., they return an

Re: [PATCH -next v9 0/2] support allocating crashkernel above 4G explicitly on riscv

2023-08-30 Thread patchwork-bot+linux-riscv
Hello: This series was applied to riscv/linux.git (for-next) by Palmer Dabbelt : On Wed, 26 Jul 2023 17:49:58 + you wrote: > On riscv, the current crash kernel allocation logic is trying to > allocate within 32bit addressible memory region by default, if > failed, try to allocate without 4G

Re: [PATCH v2 6/8] x86: kdump: use generic interface to simplify crashkernel reservation code

2023-08-30 Thread Baoquan He
ject: [PATCH v2 6/8] x86: kdump: use generic interface to simplify > crashkernel reservation code > config: x86_64-randconfig-r022-20230830 > (https://download.01.org/0day-ci/archive/20230830/202308300910.e0i4pijt-...@intel.com/config) > compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 >

Re: [RFC PATCH] Introduce persistent memory pool

2023-08-30 Thread Alexander Graf
Hi Stanislav, On 30.08.23 00:07, Stanislav Kinsburskii wrote: On Mon, Aug 28, 2023 at 10:50:19PM +0200, Alexander Graf wrote: +kexec, iommu, kvm On 23.08.23 04:45, Stanislav Kinsburskii wrote: +akpm, +linux-mm On Fri, Aug 25, 2023 at 01:32:40PM +, Gowans, James wrote: On Fri,