lkml.org 
[lkml]   [2004]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: i486 emu in mainline?
Hi Christoph,

On Sun, May 23, 2004 at 01:40:59AM +0200, Christoph Hellwig wrote:
> These days gcc uses i486+ only instruction by default in libstdc++ so
> most modern distros wouldn't work on i386 cpus anymore. To make it work
> again Debian merged Willy Tarreau's patch to trap those and emulate them
> on real i386 cpus. The patch is extremely non-invasive and would
> certainly be usefull for mainline. Any reason not to include it?

Well, I have mixed feelings about this because :

- I don't know which version they based their port on. The version
I published 2 years ago included CMOV emulation, and Denis Vlasenko
found several bugs in it which I then fixed. Since the Debian port
doesn't include CMOV, I wonder whether it includes those bugs or not
(I'll have to diff the patches).

- The code is ugly in some areas, and someone will kill me if this goes
into mainline.

- There are people (like Alan) who think that this should not go into
mainline because this is a distro problem and nothing else. He says
that only i386 packages should be installed on an i386 machine. He's
perfectly right about this. I found it interesting for people like
me who boot kernels on random machines, try to recover hard disk
contents or other things using lots of dirty tools, and sometimes
get hit by the "illegal instruction" trap. It also allowed me to
run a pppd compiled with i586 glibc on my i386 firewall, but obviously
this is just the easy way and not the right way to go.

- I couldn't emulate locks, so this will break on SMP systems, and so
will it if you need to access some memory share with an external
microcontroller or something like that.

- I've always wondered if this feature would not be exploitable to
access unauthorized information. Eg: code an invalid opcode
which would get emulated and references a memory area outside the
user space. I put some verify_area() where I thought appropriate,
but I might have left some caveats... Morten Welinder once insisted
on the fact that each byte should be read once and only once so as
to ensure that the user doesn't change the instruction while it is
being emulated. I think it's already the case. He also said that I
didn't take care of the segment selectors (such as SS) which some
programs use perfectly legally (eg Wine). I don't know how to do
that.

- Denis Vlasenko suggested that we print some messages on the console
when a program triggers the code, so as not to let the user think that
his machine is slow as hell. But for this we would need not to flood the
console (eg: once for each prog) but we don't want either to store
anything in the task structure about the message having been displayed,
so for now there's nothing. In fact, the only message which is displayed
(in the most recent version) is about a warning about a LOCK prefix on
an SMP kernel. But I didn't find it right here, so I suspect this is
based on ancient code.

- why not include the CMOV emulation while we're at it ? There are so
many people using VIA EDEN chips who think it's i686 compatible that
they may get hit too. IIRC, the chip only executes CMOV on registers,
but very slowly (a few tens of cycles), while register to memory
accesses generate a trap.

Other than that, I'm happy that someone found it useful, and happy too that
someone did the 2.6 port :-)

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.079 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site