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: <CE1F96B2-7213-4352-B80F-6E669F5EED97@Wilcox-Tech.com>
Date: Fri, 13 Dec 2024 02:42:41 -0600
From: "A. Wilcox" <AWilcox@...cox-Tech.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Arnd Bergmann <arnd@...db.de>,
 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 Dec 13, 2024, at 2:20 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> 
> On 12/13/24 09:03, Arnd Bergmann wrote:
>> On Fri, Dec 13, 2024, at 04:51, A. Wilcox wrote:
>>> On Dec 12, 2024, at 6:55 AM, Arnd Bergmann <arnd@...nel.org> wrote:
>>>> From: Arnd Bergmann <arnd@...db.de>
>>>> 
>>>> I submitted a patch to remove KVM support for x86-32 hosts earlier
>>>> this month, but there were still concerns that this might be useful for
>>>> testing 32-bit host in general, as that remains supported on three other
>>>> architectures. I have gone through those three now and prepared similar
>>>> patches, as all of them seem to be equally obsolete.
>>>> 
>>>> Support for 32-bit KVM host on Arm hardware was dropped back in 2020
>>>> because of lack of users, despite Cortex-A7/A15/A17 based SoCs being
>>>> much more widely deployed than the other virtualization capable 32-bit
>>>> CPUs (Intel Core Duo/Silverthorne, PowerPC e300/e500/e600, MIPS P5600)
>>>> combined.
>>> 
>>> 
>>> I do use 32-bit KVM on a Core Duo “Yonah” and a Power Mac G4 (MDD), for
>>> purposes of bisecting kernel issues without having to reboot the host
>>> machine (when it can be duplicated in a KVM environment).
>>> 
>>> I suppose it would still be possible to run the hosts on 6.12 LTS for
>>> some time with newer guests, but it would be unfortunate.
>> Would it be an option for you to just test those kernels on 64-bit
>> machines? I assume you prefer to do native builds on 32-bit hardware
>> because that fits your workflow, but once you get into debugging
>> in a virtual machine, the results should generally be the same when
>> building and running on a 64-bit host for both x86-32 and ppc32-classic,
>> right?
> 
> Certainly for x86-32; ppc32 should be able to use PR-state (aka
> trap and emulate) KVM on a 64-bit host but it's a bit more picky.
> Another possibility for ppc32 is just emulation with QEMU.
> 
> Paolo


Most of the reason I use KVM instead of emulation is because I don’t
trust QEMU emulation at all.  There was even a kernel bug that was
introduced affecting 32-bit x86 in the 4.0 cycle that only happened
because QEMU wasn’t emulating writes to %cr4 properly[1].  And PPC32
emulation is far worse than x86_32.  However, I probably could end
up doing x86_32 testing on a combination of bare metal machines and
KVM on x86_64, sure.

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.

-arw

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a833581e372a;
It had some form of security impact on Pentium-class machines, too,
as RDPMC became available to non-root even when /sys/devices/cpu/rdpmc
was 0.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ