This is a followup to the "Plex86 lite" that Kevin Lawton has recently managed
to get working. It seems that Kevin replaced the x86 PUSHF/POPF instructions
with macros in a "slightly modified Linux kernel" to permit native execution
as a user mode process under Plex86.
While he did hack in a tuntap network interface, the project still lacks a
decent block device abstration (ala UBD) and most of the other frills that
User Mode Linux provides. In fact, I would still consider Plex86 as more of
an "alpha" developer quality project than something you might want to
consider using on your own (or in a production capacity).
VMWare has no reason to fear Plex86... yet.
-- - Ian C. Blenke <icblenke@nks.net>(This message bound by the following: http://www.nks.net/email_disclaimer.html)
attached mail follows:
On Thursday 13 February 2003 06:56 pm, Gregory W Alexander wrote:
> Kevin Lawton wrote:
> > --- Peter Kese <peter.kese@ijs.si> wrote:
> > > My question is the following. If the pushf/popf/iret instructions are
> > > the only ones that need to be macroized, could they also be somehow
> > > replaced by a one instruction jump like 'break into interrupt' as is
> > > done by debuggers?
[snip]
> > There's a few more instructions you'd have to catch, but for
> > running Linux it doesn't matter. Anyways, for running random OSes
> > you need much more than the minimal framework of plex86. You
> > need not only complete emulation (which really is due to a few
> > broken instructions in the end), plus all the IO framework.
> > And as well, all the 16-bit stuff - plex86 doesn't know anything
> > about 16-bit code. So here, plex86 is really just an accelerator
> > for when user code is running (32-bit protected mode) and the conditions
> > are good. Which could be a decent chunk of execution time.
>
> I would think that you could run "virtualization-friendly" kernel code
> as well, where a trapped instruction would just get passed back to bochs
> as "Plex86 didn't like this instruction, please rerun it and do the
> right thing." This should be quite small and auditable, as all that
> Plex86 would be doing is passing the information that was passed with
> the exception back into user space. (for bochs/plex86, not plex86
> Linux-on-Linux)
What you have just described is the main difference between the original
plex86 effort and what Kevin has implemented so far (or course, I'm not
speaking for him, so I could be wrong about this). The issue is that there
are x86 instructions which can't easily (or securely) be virtualized, but do
*not* trap.
Off the top of my head (so not a complete listing), these instructions are:
PUSHF, POPF (leak virtual interrupt flag status)
SGDT, SLDT (leak the locations of the segment descriptor tables)
LAR, LSL, ARPL, VERR, VERW (prevent you from playing dirty tricks with
segmentation)
SLDT (I'm unsure if this works in user-mode, but I seem to remember that it
does)
Since these instructions do not trap, the virtual machine monitor can not
execute untrusted code. You can play tricks with the MMU, and scan each page
for nasty instructions before marking it execute-ok (it is more complicated
than this, b/c 386 page tables do not have an "execute permission" flag, but
there are some clever tricks that can achieve a similar effect).
But it was precisely this scanning-for-bad-instructions and
playing-games-with-the-TLB-to-emulate-an-execute-permisison-flag that made
the old plex86 so complicated. The new design works with Linux, because the
only "virtualization unfriendly" instructions Linux uses are PUSH + POPF, and
these can be changed in a minimally-invasive way.
Also note that the current Linux virtualization does not try to hide the fact
that it is a virtual machine -- that information leaks through the "virtual
interrupt flag", which is visible to user-space. (I'm not 100% sure about
this; I haven't seen the new plex86 code, but I can't think of a simple way
to prevent it)
> It's not clear what the performance implications of such a setup would
> be, but it should be fairly easily implementable.
If the virtual machine monitor were extended to be able to deal with arbitrary
blocks of x86 code, the performance would likely be similar to that of
VMWare, which uses a similar technique. And I don't think "easy" would be
the right way to describe such a system. Even if you decide to do a
no-frills, unoptimized implementation, it ends up having to be complicated
because it is implementing some of the most subtle aspects of the 386
architecture (which is *plenty* complicated ;)
-Eric
-------------------------------------------------------
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
_______________________________________________
Plex86-developers mailing list
Plex86-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plex86-developers
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:21:21 EDT