Re: qemu-user viability (was Re: [SECURITY] [DSA 5983-1] qemu security update)

Hello,

On Sun, 2025-08-24 at 13:07 -0500, Rob Landley wrote:
> On 8/23/25 09:19, Thorsten Glaser wrote:
> > > There are no alternatives - qemu is unique in this regard.  And
> > > it has never been designed for this usage.  What we had for 15+
> > > years, unnoticed, is like `chmod u+s /bin/sh`, which is never
> > > supposed to be used like this.
> > 
> > Perhaps, but there’s shades in between.
> 
> I find qemu system emulation a LOT less problematic.
> 
> For sh4 I boot qemu-system-sh4 and then use a network block device to 
> provide swap (so the 64mb limitation of the board isn't a limiting 
> factor). The sh4 build in toybox's mkroot works fine for this (binaries 
> at https://landley.net/bin/mkroot if you'd like to try). It also works 
> with -hda but I think can only provide _one_ of those so you have to 
> partition it, which I generally don't bother.

Building packages with just 64 MB is nearly impossible which is why qemu-system
is not really suitable for my usecase. There are plans to add Goldfish support
for sh4 similar to m68k but I don't know when this is going to happen.

> > Yes. People expect to be able to run foreign-arch chroots.
> > Entire buildd setups partly rely on this, too…
> 
> A qemu-system vm doesn't require any weird translation. As far as the 
> kernel running in the emulator is concerned, everything is entirely 
> native. :)

Did you ever try building GCC or WebKit with qemu-system for sh4?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913