lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 30 Nov 2023 11:16:29 +0100
From:   Michal Hocko <mhocko@...e.com>
To:     Baoquan He <bhe@...hat.com>
Cc:     Donald Dutile <ddutile@...hat.com>, Jiri Bohac <jbohac@...e.cz>,
        Pingfan Liu <piliu@...hat.com>, Tao Liu <ltao@...hat.com>,
        Vivek Goyal <vgoyal@...hat.com>,
        Dave Young <dyoung@...hat.com>, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] kdump: crashkernel reservation from CMA

On Thu 30-11-23 11:00:48, Baoquan He wrote:
[...]
> Now, we are worried if there's risk if the CMA area is retaken into kdump
> kernel as system RAM. E.g is it possible that 1st kernel's ongoing RDMA
> or DMA will interfere with kdump kernel's normal memory accessing?
> Because kdump kernel usually only reset and initialize the needed
> device, e.g dump target. Those unneeded devices will be unshutdown and
> let go. 

I do not really want to discount your concerns but I am bit confused why
this matters so much. First of all, if there is a buggy RDMA driver
which doesn't use the proper pinning API (which would migrate away from
the CMA) then what is the worst case? We will get crash kernel corrupted
potentially and fail to take a proper kernel crash, right? Is this
worrisome? Yes. Is it a real roadblock? I do not think so. The problem
seems theoretical to me and it is not CMA usage at fault here IMHO. It
is the said theoretical driver that needs fixing anyway.

Now, it is really fair to mention that CMA backed crash kernel memory
has some limitations
	- CMA reservation can only be used by the userspace in the
	  primary kernel. If the size is overshot this might have
	  negative impact on kernel allocations
	- userspace memory dumping in the crash kernel is fundamentally
	  incomplete.

Just my 2c
-- 
Michal Hocko
SUSE Labs

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ