linux-kernel - Re: [RFC 0/5] KVM: drop 32-bit host support on all architectures

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: <1c8ce6c9-6693-4cfb-8e40-3a641734daff@app.fastmail.com>
Date: Fri, 13 Dec 2024 10:01:30 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "A. Wilcox" <AWilcox@...cox-tech.com>,
 "Paolo Bonzini" <pbonzini@...hat.com>
Cc: "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>,
 "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: [RFC 0/5] KVM: drop 32-bit host support on all architectures

On Fri, Dec 13, 2024, at 09:42, A. Wilcox wrote:
>
> As for Power: I will admit I haven’t tested lately, but well into
> the 5 series (5.4, at least), you couldn’t boot a ppc32 Linux kernel
> on any 64-bit capable hardware.  It would throw what I believe was an
> alignment error while quiescing OpenFirmware and toss you back to an
> ‘ok >’ prompt.  Unfortunately I can’t find any of the bug reports
> or ML threads from the time - it was a known bug in the 2.6 days - but
> the answer was always “why are you booting a ppc32 kernel on that
> hardware anyway?  It’s a ppc64 machine!”  Is this a case where
> that would be accepted as a legitimate bug now?  It would be lovely
> to use my largely-SMT 3.0 GHz Power9 box for more of my kernel testing
> (where possible) instead of relying on a 933 MHz single-thread G4.

I'm fairly sure we don't allow booting 32-bit kernels on
the 64-bit IBM CPUs (g5, cell, POWER), but as Christophe
mentioned earlier, you can apparently run a 32-bit e500
kernel 64-bit QorIQ.

What I was thinking of is purely inside of qemu/kvm. I have
not tried this myself, but I saw that there is code to handle
this case in the kernel, at least for PR mode:

static void kvmppc_set_pvr_pr(struct kvm_vcpu *vcpu, u32 pvr)
{
        u32 host_pvr;

        vcpu->arch.hflags &= ~BOOK3S_HFLAG_SLB;
        vcpu->arch.pvr = pvr;
        if ((pvr >= 0x330000) && (pvr < 0x70330000)) {
                kvmppc_mmu_book3s_64_init(vcpu);
                if (!to_book3s(vcpu)->hior_explicit)
                        to_book3s(vcpu)->hior = 0xfff00000;
                to_book3s(vcpu)->msr_mask = 0xffffffffffffffffULL;
                vcpu->arch.cpu_type = KVM_CPU_3S_64;
        } else
        {
                kvmppc_mmu_book3s_32_init(vcpu);
                if (!to_book3s(vcpu)->hior_explicit)
                        to_book3s(vcpu)->hior = 0;
                to_book3s(vcpu)->msr_mask = 0xffffffffULL;
                vcpu->arch.cpu_type = KVM_CPU_3S_32;
        }
...

So I assumed this would work the same way as on x86 and arm,
where you can use the 32-bit machine emulation from qemu but
still enable KVM mode.

      Arnd