linux-kernel - RE: [PATCH v3 1/3] arm64, vmcoreinfo : Append 'PTRS_PER

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]

Message-ID: <4AE2DC15AC0B8543882A74EA0D43DBEC035710C4@BPXM09GP.gisp.nec.co.jp>
Date:   Wed, 27 Mar 2019 16:07:22 +0000
From:   Kazuhito Hagio <k-hagio@...jp.nec.com>
To:     James Morse <james.morse@....com>,
        Bhupesh Sharma <bhsharma@...hat.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Mark Rutland" <mark.rutland@....com>,
        Will Deacon <will.deacon@....com>,
        "Dave Anderson" <anderson@...hat.com>,
        "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Steve Capper <Steve.Capper@....com>
Subject: RE: [PATCH v3 1/3] arm64, vmcoreinfo : Append 'PTRS_PER_PGD' to
 vmcoreinfo

On 3/26/2019 12:36 PM, James Morse wrote:
> Hi Bhupesh,
> 
> On 20/03/2019 05:09, Bhupesh Sharma wrote:
> > With ARMv8.2-LVA architecture extension availability, arm64 hardware
> > which supports this extension can support a virtual address-space upto
> > 52-bits.
> >
> > Since at the moment we enable the support of this extension in kernel
> > via CONFIG flags, e.g.
> >  - User-space 52-bit LVA via CONFIG_ARM64_USER_VA_BITS_52
> >
> > so, there is no clear mechanism in the user-space right now to
> > determine these CONFIG flag values and hence determine the maximum
> > virtual address space supported by the underlying kernel.
> >
> > User-space tools like 'makedumpfile' therefore are broken currently
> > as they have no proper method to calculate the 'PTRS_PER_PGD' value
> > which is required to perform a page table walk to determine the
> > physical address of a corresponding virtual address found in
> > kcore/vmcoreinfo.
> >
> > If one appends 'PTRS_PER_PGD' number to vmcoreinfo for arm64,
> > it can be used in user-space to determine the maximum virtual address
> > supported by underlying kernel.
> 
> I don't think this really solves the problem, it feels fragile.
> 
> I can see how vmcoreinfo tells you VA_BITS==48, PAGE_SIZE==64K and PTRS_PER_PGD=1024.
> You can use this to work out that the top level page table size isn't consistent with a
> 48bit VA, so 52bit VA must be in use...
> 
> But wasn't your problem walking the kernel page tables? In particular the offset that we
> apply because the tables were based on a 48bit VA shifted up in swapper_pg_dir.
> 
> Where does the TTBR1_EL1 offset come from with this property? I assume makedumpfile
> hard-codes it when it sees 52bit is in use ... somewhere.

My understanding is that the TTBR1_EL1 offset comes from a kernel
virtual address with the exported PTRS_PER_PGD.

With T1SZ is 48bit and T0SZ is 52bit,

kva = 0xffff000000000000    <--- start of kernel virtual address
pgd_index(kva) = (kva >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1)
               = (0xffff000000000000 >> 42) & (1024 - 1)
               = 0x00000000003fffc0 & 0x3ff
               = 0x3c0      <--- the offset (0x3c0) is included

This is what kernel does now, so makedumpfile also wants to do.

> We haven't solved the problem!
> 
> Today __cpu_setup() sets T0SZ and T1SZ differently for 52bit VA, but in the future it
> could set them the same, or different the other-way-round.
> 
> Will makedumpfile using this value keep working once T1SZ is 52bit VA too? In this case
> there would be no ttbr offset.

If T1SZ is 52bit, probably kernel virtual address starts from 0xfff0000000000000,
then the offset becomes 0 with the pgd_index() above.
I think makedumpfile will keep working with that.

Thanks,
Kazu

> 
> If you need another vmcoreinfo flag once that happens, we've done something wrong here.
> 
> (Not to mention what happens if the TTBR1_EL1 uses 52bit va, but TTBR0_EL1 doesn't)
> 
> 
> > Suggested-by: Steve Capper <Steve.Capper@....com>
> 
> (CC: +Steve)
> 
> 
> Thanks,
> 
> James