| 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
| ||
|
Date: Wed, 24 Jul 2019 15:57:33 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Steven Price <steven.price@....com>
cc: Mark Rutland <mark.rutland@....com>, x86@...nel.org,
Arnd Bergmann <arnd@...db.de>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Catalin Marinas <catalin.marinas@....com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Jérôme Glisse <jglisse@...hat.com>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Andy Lutomirski <luto@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
James Morse <james.morse@....com>,
Will Deacon <will@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-arm-kernel@...ts.infradead.org,
"Liang, Kan" <kan.liang@...ux.intel.com>
Subject: Re: [PATCH v9 00/21] Generic page walk and ptdump
On Wed, 24 Jul 2019, Steven Price wrote:
> On 23/07/2019 11:16, Mark Rutland wrote:
> > Are there any visible changes to the arm64 output?
>
> arm64 output shouldn't change. I've confirmed that "efi_page_tables" is
> identical on a Juno before/after the change. "kernel_page_tables"
> obviously will vary depending on the exact layout of memory, but the
> format isn't changed.
>
> x86 output does change due to patch 14. In this case the change is
> removing the lines from the output of the form...
>
> > 0xffffffff84800000-0xffffffffa0000000 440M pmd
>
> ...which are unpopulated areas of the memory map. Populated lines which
> have attributes are unchanged.
Having the hole size and the level in the dump is a very conveniant thing.
Right now we have:
0xffffffffc0427000-0xffffffffc042b000 16K ro NX pte
0xffffffffc042b000-0xffffffffc042e000 12K RW NX pte
0xffffffffc042e000-0xffffffffc042f000 4K pte
0xffffffffc042f000-0xffffffffc0430000 4K ro x pte
0xffffffffc0430000-0xffffffffc0431000 4K ro NX pte
0xffffffffc0431000-0xffffffffc0433000 8K RW NX pte
0xffffffffc0433000-0xffffffffc0434000 4K pte
0xffffffffc0434000-0xffffffffc0436000 8K ro x pte
0xffffffffc0436000-0xffffffffc0438000 8K ro NX pte
0xffffffffc0438000-0xffffffffc043a000 8K RW NX pte
0xffffffffc043a000-0xffffffffc043f000 20K pte
0xffffffffc043f000-0xffffffffc0444000 20K ro x pte
0xffffffffc0444000-0xffffffffc0447000 12K ro NX pte
0xffffffffc0447000-0xffffffffc0449000 8K RW NX pte
0xffffffffc0449000-0xffffffffc044f000 24K pte
0xffffffffc044f000-0xffffffffc0450000 4K ro x pte
0xffffffffc0450000-0xffffffffc0451000 4K ro NX pte
0xffffffffc0451000-0xffffffffc0453000 8K RW NX pte
0xffffffffc0453000-0xffffffffc0458000 20K pte
0xffffffffc0458000-0xffffffffc0459000 4K ro x pte
0xffffffffc0459000-0xffffffffc045b000 8K ro NX pte
with your change this becomes:
0xffffffffc0427000-0xffffffffc042b000 16K ro NX pte
0xffffffffc042b000-0xffffffffc042e000 12K RW NX pte
0xffffffffc042f000-0xffffffffc0430000 4K ro x pte
0xffffffffc0430000-0xffffffffc0431000 4K ro NX pte
0xffffffffc0431000-0xffffffffc0433000 8K RW NX pte
0xffffffffc0434000-0xffffffffc0436000 8K ro x pte
0xffffffffc0436000-0xffffffffc0438000 8K ro NX pte
0xffffffffc0438000-0xffffffffc043a000 8K RW NX pte
0xffffffffc043f000-0xffffffffc0444000 20K ro x pte
0xffffffffc0444000-0xffffffffc0447000 12K ro NX pte
0xffffffffc0447000-0xffffffffc0449000 8K RW NX pte
0xffffffffc044f000-0xffffffffc0450000 4K ro x pte
0xffffffffc0450000-0xffffffffc0451000 4K ro NX pte
0xffffffffc0451000-0xffffffffc0453000 8K RW NX pte
0xffffffffc0458000-0xffffffffc0459000 4K ro x pte
0xffffffffc0459000-0xffffffffc045b000 8K ro NX pte
which is 5 lines less, but a pain to figure out the size of the holes. And
it becomes even more painful when the holes go across different mapping
levels.
>From your 14/N changelog:
> This keeps the output shorter and will help with a future change
I don't care about shorter at all. It's debug information.
> switching to using the generic page walk code as we no longer care about
> the 'level' that the page table holes are at.
I really do not understand why you think that WE no longer care about the
level (and the size) of the holes. I assume that WE is pluralis majestatis
and not meant to reflect the opinion of you and everyone else.
I have no idea whether you ever had to do serious work with PT dump, but I
surely have at various occasions including the PTI mess and I definitely
found the size and the level information from holes very useful.
Thanks,
tglx
Powered by blists - more mailing lists