Bugzilla Bug 212351

Ian Jackson discovered that accesses beyond end of qemu emulated disk devices
can result in accesses to emulator's virtual memory space accesses and thus can
allow user with sufficient privilege in guest (root, as this would need
modification to kernel's driver) to break out of VM.

Solution:
apply Patch: https://bugzilla.redhat.com/attachment.cgi?id=296005

maintainer - please provide an updated ebuild

also affects Xen

*** Bug 211442 has been marked as a duplicate of this bug. ***

updated ebuild provided, please test

Did you commit it, I can't see anything in CVS.

app-emulation/qemu-softmmu

qemu is just a meta ebuild.

Ah, sorry, I missed that.

Arches, please test and mark stable:
=app-emulation/qemu-softmmu-0.9.1-r1
Target keywords : "amd64 ppc release x86"

Luca, you use it on x86?  I don't have GCC 3 here at the moment...so a
successful ok from you would be enough for me.

I don't have x86 around to test it properly =/

I should check a snapshot with the replaced dygen so the gcc-3 constraint would
disappear.

same for me, no gcc-3 on ppc ... luca, can you keyword this package for ppc? ;)

Created an attachment (id=145714) [details]
build.log

Fails here.

Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-3.4.6, glibc-2.6.1-r0,
2.6.24-gentoo-r3 i686)
=================================================================
System uname: 2.6.24-gentoo-r3 i686 AMD Athlon(tm) X2 Dual Core Processor
BE-2400
Timestamp of tree: Mon, 10 Mar 2008 06:30:01 +0000
app-shells/bash:     3.2_p17-r1
dev-java/java-config: 1.3.7, 2.1.4
dev-lang/python:     2.4.4-r9
dev-python/pycrypto: 2.0.1-r6
sys-apps/baselayout: 1.12.11.1
sys-apps/sandbox:    1.2.18.1-r2
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.18-r1
sys-devel/gcc-config: 1.4.0-r4
sys-devel/libtool:   1.5.26
virtual/os-headers:  2.6.23-r3
ACCEPT_KEYWORDS="x86"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config
/usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown
/usr/share/config /var/lib/hsqldb /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf
/etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/
/etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo
/etc/texmf/web2c /etc/udev/rules.d"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms
strict unmerge-orphans userfetch userpriv"
GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/"
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LINGUAS="de"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --stats --timeout=180 --exclude=/distfiles
--exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise"
SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage"
USE="3dnow 3dnowext X a52 acl acpi aiglx alsa apache2 apm applet artworkextra
asf audiofile avahi bash-completion beagle berkdb bidi bogofilter bootsplash
branding bzip2 cairo ccache cdda cddb cdparanoia cdr cli console cracklib crypt
css cups curl custom-cflags dbus dga directfb divx4linux dri dts dvd dvdr
dvdread dvi eds emacs emboss encode esd evince evo exif fam fat fbcon fdftk
ffmpeg firefox flac foomaticdb fortran ftp gb gcj gdbm gif glitz gnome gpm gsf
gstreamer gtk gtk2 gtkhtml hal howl iconv icq idn imagemagick imap imlib
immqt-bc isdnlog java javascript jpeg jpeg2k kde ldap libnotify lirc lm_sensors
mad maildir matroska mbox midi mikmod mime mmx mmxext mng mono mp3 mpeg mpeg2
mudflap mule mysql nautilus ncurses nforce2 nls nocardbus nptl nptlonly
nsplugin nvidia objc objc++ objc-gc offensive ogg opengl openmp pam pango pcre
pdf perl php plotutils pmu png ppds pppd prediction preview-latex print python
qt3 qt3support qt4 quicktime readline reflection samba sdk session slang spell
spl sse ssl svg svga t1lib tcl tcpd tetex theora threads thumbnailing tiff tk
toolkit-scroll-bars totem tracker truetype truetype-fonts type1-fonts udev
unicode usb userlocales vcd videos vorbis win32codecs wmf wxwindows x86 xface
xft xine xml xorg xosd xpm xv xvid zlib" ALSA_CARDS="intel8x0"
ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file
hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route
share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias
authn_anon authn_dbm authn_default authn_file authz_dbm authz_default
authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs
dav_lock deflate dir disk_cache env expires ext_filter file_cache filter
headers include info log_config logio mem_cache mime mime_magic negotiation
rewrite setenvif speling status unique_id userdir usertrack vhost_alias"
CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="mouse keyboard"
KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001
mtxorb ncurses text" LINGUAS="de" LIRC_DEVICES="atiusb" USERLAND="GNU"
VIDEO_CARDS="vesa fbdev fglrx"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS,
PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

Worked on ppc

../softmmu_template.h:260: error: unable to find a register to spill in class
`GENERAL_REGS'

x86 vs gcc vs qemu on register allocation. That is a gcc bug

(In reply to comment #13)
> ../softmmu_template.h:260: error: unable to find a register to spill in class
> `GENERAL_REGS'
> 
> x86 vs gcc vs qemu on register allocation. That is a gcc bug

 And now?  It is unlikely that a fixed GCC 3 release will appear.  My proposal,
as GCC 3 is hard masked and needed: Mask qemu, too, until they fix their
compiler problem in general.

just use another gcc-3.4 =/ or dekeyword it for x86 qemu builds fine on the
other arches.

Could someone from x86 verify my failures?

Luca, normally a package that has hard-masked dependencies should not go
stable.

qemu-softmmu builds and works apparently well enough for everybody but x86
users with the latest gcc-3.4 since the register allocation is problematic and
the underlying hardware has limited registers.

Seems my grep foo has left me, where is <gcc-4 hard masked?

(In reply to comment #18)
> Seems my grep foo has left me, where is <gcc-4 hard masked?

 You should have looked in my local package.mask....

Could anybody from x86 verify that it does not work?

Verified:

/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:
In function `op_psrlq_mmx':
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:213:
error: unable to find a register to spill in class `GENERAL_REGS'
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:213:
error: this is the insn:
(insn:HI 36 35 37 3
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:207
(parallel [
            (set (reg:DI 63 [ <variable>.q ])
                (lshiftrt:DI (reg:DI 63 [ <variable>.q ])
                    (subreg:QI (reg/v:SI 60 [ shift ]) 0)))
            (clobber (scratch:SI))
            (clobber (reg:CC 17 flags))
        ]) 309 {lshrdi3_1} (insn_list 33 (insn_list 35 (nil)))
    (expr_list:REG_DEAD (reg/v:SI 60 [ shift ])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (expr_list:REG_UNUSED (scratch:SI)
                (nil)))))
/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/target-i386/ops_sse.h:213:
confused by earlier errors, bailing out
make[1]: *** [op.o] Error 1
make[1]: Leaving directory
`/var/tmp/paludis/app-emulation/qemu-softmmu-0.9.1-r1/work/qemu-0.9.1/i386-softmmu'
make: *** [subdir-i386-softmmu] Error 2

So what do we do? Drop x86 keyword at all?

(In reply to comment #9)
> I should check a snapshot with the replaced dygen so the gcc-3 constraint would
> disappear.

This sounds more promising for the future than dropping qemu support.

(In reply to comment #21)
> (In reply to comment #9)
> > I should check a snapshot with the replaced dygen so the gcc-3 constraint would
> > disappear.
> 
> This sounds more promising for the future than dropping qemu support.

 GCC 3.3.6 works.  Problem: Not marked stable and I am not sure if i want to do
it.  People will try 3.4 when asked for GCC 3...
 Dropping stable x86 is also no desired option, so this snapshot seems to be
the best solution.  Luca, your turn again. :)

I'll try to prepare something, then I'll need somebody to test it

Snapshot does has the same bugs. But, please, take a look at this thread:

http://lists.gnu.org/archive/html/qemu-devel/2008-03/msg00243.html

I'm about to suggest solution...

(In reply to comment #23)
> I'll try to prepare something, then I'll need somebody to test it

 We are here.

(In reply to comment #24)
> Snapshot does has the same bugs. But, please, take a look at this thread:
> 
> http://lists.gnu.org/archive/html/qemu-devel/2008-03/msg00243.html
> 
> I'm about to suggest solution...

 Yes?  I did not try the patch suggested there yet, BUT I don't have a march
setting in my CFLAGS, so this is not the solution.

Created an attachment (id=146286) [details]
qemu-softmmu-0.9.1-r1.patch

Well, this patch fixes the build problem with gcc-3.4 here. Although I think
that forcing -march is a good idea this is a good first approximation. BTW I've
tried to build with "-no-sse{,2,3} -mfpmath=387" and this didn't worked. Also
for unknown reason it fails if I don't pass OS_CFLAGS="${CFLAGS}" to emake too.

Questions remain: 1. is it possible that -02 or -g redefines -march defaults
and enables sse? 2. What -march=pentium-mmx enables/disables to make
compilation succeed?

(In reply to comment #25)
> I did not try the patch suggested there yet, BUT I don't have a march
> setting in my CFLAGS, so this is not the solution.

And to save your time: patches suggested there do not fix anything here.

Created an attachment (id=146291) [details]
Fixing some QA things and the actual bug fix

I reworked your patch (use x86 instead of querying ${ARCH}, adjusted comment),
use emake install instead of plain make and a comment that econf is not
possible.

Luca, this compiles, I have still to check if it works.

Christian, as I wrote in #26 build fails if you do not pass
OS_CFLAGS="${CFLAGS}" to emake. I've checked. Build fails with your patch here.

(In reply to comment #28)
> Created an attachment (id=146291) [edit] [details]
> Fixing some QA things and the actual bug fix
> 
> I reworked your patch (use x86 instead of querying ${ARCH}, adjusted comment),
> use emake install instead of plain make and a comment that econf is not
> possible.
> 
> Luca, this compiles, I have still to check if it works.
> 
It compiles also here and it works. I could successfully boot from hard disk.
So the only things left are question in the bug. :)

(In reply to comment #29)
> Christian, as I wrote in #26 build fails if you do not pass
> OS_CFLAGS="${CFLAGS}" to emake. I've checked. Build fails with your patch here.

 Are you sure you applied my patch?  As far as I can see, the OS_CFLAGS is
there.

(In reply to comment #31)
>  Are you sure you applied my patch?  As far as I can see, the OS_CFLAGS is
> there.

Ah, sure. I'm sorry. I've applied manually and I confused + with - :)

Luca, instead of -march=pentium-mmx, -march=i486 is sufficient to avoid that
error.  Could you please apply the patch with that little change?  Peter
confirmed that it is working on his system.

Created an attachment (id=146567) [details]
qemu-softmmu-0.9.1-r1.patch

Small update. Seems that qemu-softmmu builds with any -march lower than
pentium-mmx. I've created IMHO better patch. The ideas I've took from
gcc/config.gcc so I suppose I didn't missed anything. General idea of this
patch: if user forced lower march take that, if not, use CHOST to set lowest
cpu.

We are playing with gcc here, so I think it's good idea if toolchain guys
review and comment our work here, before we commit anything to the tree. Thank
you in advance.

try to force just the march flag adding more random cflags may cause other
breakage

so we're clear, you're not talking about changing the gcc package, just
tweaking gcc CFLAGS in the qemu ebuild

(In reply to comment #35)
> We are playing with gcc here, so I think it's good idea if toolchain guys
> review and comment our work here, before we commit anything to the tree. Thank
> you in advance.

 Peter, I think you applied the same patch again.  Or is it just me?

(In reply to comment #37)
> so we're clear, you're not talking about changing the gcc package, just
> tweaking gcc CFLAGS in the qemu ebuild

 Right-

Created an attachment (id=146640) [details]
qemu-softmmu-0.9.1-r1.ebuild.patch

Yea, I should clean my /tmp more regulary ... Applying correct patch.

Fixing this security issue we are getting regression: qemu does not boot with
qcow2 image files:
 # qemu-img create -f qcow c.img 3G
Formatting 'c.img', fmt=qcow, size=3145728 kB
# qemu -cdrom install-x86-minimal-2007.0-r1.iso -hda ./c.img -m 256 -boot d
qemu: could not open disk image ./c.img

I've checked without patch everything works. Similar issue is reported at
debian: http://bugs.debian.org/470664

qcow2 - is default and recommended format... what shall we do?

(In reply to comment #40)
> qcow2 - is default and recommended format... what shall we do?

 Most simple fix -> drop stable x86

I don't really like this, but fixing QEmu must be really hard here with an
outdated GCC 3.4*.  Still people seem to know that they switch to GCC 3.3* if
they have problems (according to Gentoo Wiki), so this problem is no
regression.

(In reply to comment #41)
>  Most simple fix -> drop stable x86

Dropping keyword does not fixe the problem. Also I see your point.

> I don't really like this, but fixing QEmu must be really hard here with an
> outdated GCC 3.4*.  Still people seem to know that they switch to GCC 3.3* if
> they have problems (according to Gentoo Wiki), so this problem is no
> regression.

Upstream FAQ suggests that both gcc versions are supported.

Well that's said take a look at bug, comment #22:
https://bugzilla.redhat.com/show_bug.cgi?id=433560

seems that there is new patch that fixes regression too. Luca, please, update
ebuild with that patch and patch from comment #39, if you agree with that
solution. BTW, I have not tested patch from redhat yet, but it's already works
for one distribution so I suppose it should work for us too. Will test later.

Hardened user came on irc today.  Couldn't use gcc 3.4 because of this bug, nor
gcc 3.3 due to hitting bug 166392.  And of course gcc 4.x is not supported.

Ok, while building with gcc-3.4 is more upstream issue, security should be
fixed as much as possible so I've went ahead and commited ebuild suggested in
#39 + updated security patch which avoids qcow2 regression. So I think we
should re'CC ppc team and proceed stabilization...

thank you, sorry for being unresponsive.

x86 stable, Luca can handle PPC.

stabling now in bug 221943