linux-kernel - Re: [PATCH v2 4/5] powerpc: kvm: drop 32-bit book3s

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: <20241222222325.GD20626@gate.crashing.org>
Date: Sun, 22 Dec 2024 16:23:26 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: "A. Wilcox" <AWilcox@...cox-tech.com>, Arnd Bergmann <arnd@...nel.org>,
        kvm@...r.kernel.org, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Huacai Chen <chenhuacai@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Nicholas Piggin <npiggin@...il.com>,
        Christophe Leroy <christophe.leroy@...roup.eu>,
        Naveen N Rao <naveen@...nel.org>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Alexander Graf <graf@...zon.com>, Crystal Wood <crwood@...hat.com>,
        Anup Patel <anup@...infault.org>, Atish Patra <atishp@...shpatra.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
        Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>, Paul Durrant <paul@....org>,
        Marc Zyngier <maz@...nel.org>, linux-kernel@...r.kernel.org,
        linux-mips@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
        kvm-riscv@...ts.infradead.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 4/5] powerpc: kvm: drop 32-bit book3s

On Sun, Dec 22, 2024 at 10:09:14PM +0100, Arnd Bergmann wrote:
> On Sun, Dec 22, 2024, at 03:13, A. Wilcox wrote:
> > On Dec 21, 2024, at 3:42 PM, Arnd Bergmann <arnd@...nel.org> wrote:
> >
> >     R0 .. R7           R8 .. R15         R16 .. R23         R24 .. R31
> > 00000000014a1124   0000000000000000   000000000135b4ac   0000000000000000   
> > 000000000dc70f30   ffffffffc0000000   000000000dc70fa4   000000000173600c   
> > 0000000000000000   000000000e477010   0000000000000000   0000000000400000   
> > ffffffff0141be4c   000000000149ab74   00000000ffffffff   0000000000000008   
> > 00000000c0014b6c   0000000020000402   0000000040400000   00000000016f2000   
> > ffffffff40400000   0000000000000000   0000000000000000   000000000dc70f60   
> > 0000000000000000   0000000000000000   000000000e73d490   000000000149f000   
> > 0000000000000000   000000000e756118   000000000dc70fa0   ffffffff40400000   
> >
> >     CR / XER           LR / CTR          SRR0 / SRR1        DAR / DSISR
> >         80000402   00000000014a1124   00000000014a1128   ffffffff0141be4c   
> > 0000000020040000   0000000000000000   8000000000003000           00000000   
> >
> >
> > 2 > 
> >
> > Which is the same thing that happens if you boot a 32-bit Linux kernel
> > on a physical 64-bit Power machine.  This is probably because KVM is
> > so much more accurate than TCG for Power emulation :)
> 
> Did you ask kvm to emulate a 32-bit platform though? Since the
> register dump shows 64-bit registers, my guess is that this is the
> result of trying to load a 32-bit kernel on "-machine pseries
> -cpu native", which is not supported by the guest kernel. I would
> expect that you need at least a 32-bit machine type (mac99,
> pegasos2) and likely also a 32-bit CPU (7447a, e600).

SLOF always shows 64-bit registers; SLOF only ever runs as 64-bit
program.  The *client* program can be 32-bit of course, but the dump
of SRR1 here shows SF=1 (the top bit there).  No idea what was running
at the time, but something in the kernel I guess?

(To show the last set client state, use
  ciregs .regs
the thing exceptions print is via
  eregs .regs
so you'll probably figure out the format ;-) )

If the client program is a 32-bit ELF file, SLOF starts the client
program with SF=0.


Segher