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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 16 Feb 2022 12:40:27 +0000
From:   Will Deacon <will@...nel.org>
To:     Huang Shijie <shijie@...amperecomputing.com>
Cc:     catalin.marinas@....com, bhe@...hat.com, vgoyal@...hat.com,
        dyoung@...hat.com, corbet@....net, kexec@...ts.infradead.org,
        linux-doc@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, zwang@...erecomputing.com,
        patches@...erecomputing.com, darren@...amperecomputing.com
Subject: Re: [PATCH] arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP
 ranges

On Wed, Feb 16, 2022 at 09:28:49AM +0000, Huang Shijie wrote:
> Hi Will,
> On Tue, Feb 15, 2022 at 04:44:23PM +0000, Will Deacon wrote:
> > On Wed, Feb 09, 2022 at 09:26:42AM +0000, Huang Shijie wrote:
> > > The following interrelated ranges are needed by the kdump crash tool:
> > > 	MODULES_VADDR ~ MODULES_END,
> > > 	VMALLOC_START ~ VMALLOC_END,
> > > 	VMEMMAP_START ~ VMEMMAP_END
> > > 
> > > Since these values change from time to time, it is preferable to export
> > > them via vmcoreinfo than to change the crash's code frequently.
> > 
> > Please can you explain _why_ they are needed?
> 
> The current Crash code is still based at kernel v4.9.
>    The virtual memory layout looks like this:
>    +--------------------------------------------------------------------+
>    |    KASAN     |   MODULE   |   VMALLOC   | .... |     VMEMMAP       |
>    +--------------------------------------------------------------------+
> 
> The Crash uses MODULES range to set the VMALLOC ranges.
> If the ranges are wrong, Crash will _NOT_ works well for some latest kernel
> ,such as v5.11 later. (Please correct me if I am wrong).
> It seems the VMEMMAP range is less important.

[...]

> 5.) In the kernel v5.16, after the patch
>       "b89ddf4cca43 arm64/bpf: Remove 128MB limit for BPF JIT programs"
>     the virtual memory layout looks like this:
> 
>    +--------------------------------------------------------------------+
>    |      MODULE     |   VMALLOC   |     ....     |      VMEMMAP        |
>    +--------------------------------------------------------------------+
> 
>     The macros are:
>     #define MODULES_VADDR	(_PAGE_END(VA_BITS_MIN))
>     #define MODULES_END		(MODULES_VADDR + MODULES_VSIZE)
> 
>     #define VMALLOC_START	(MODULES_END)
>     #define VMALLOC_END		(VMEMMAP_START - SZ_256M)
> 
>     #define VMEMMAP_START	(-(UL(1) << (VA_BITS - VMEMMAP_SHIFT)))
>     #define VMEMMAP_END		(VMEMMAP_START + VMEMMAP_SIZE)
> 
> 
> BTW:I am currently coding a patch for the Crash to update all the ranges to
> the latest kernel version v5.17-rc4.

Thanks for digging up all of the kernel memory map changes and taking the
time to explain the macros. However, all I'm really after is something in
the commit message of the patch which explains what is broken without this
patch. What does crash use this information for, and what doesn't work at
the moment?

Cheers,

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ