Hello all,
I'm working on running Linux as a guest OS inside a
lightweight cut-down plex86 environment. My goal is to
run a stock Linux kernel, which can be slimmed down to
the essentials via kernel configuration, since a guest
OS doesn't need to drive much hardware.
For this, there's a few critical but simple diffs to
macro'ize the use of the PUSHF and POPF instructions,
due to broken semantics of running stuff using
PVI (protected mode virtual interrupts). The rest of
the stuff I believe can be monitored effectively by
the VM monitor.
Would you please consider integrating these diffs before 2.6?
There's only one new header file, and macro substitution for
a few cases where these instructions are used. For a normal
compile, there are zero logic changes. Just 1:1 macros.
Thanks much,
-Kevin Lawton
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Kevin Lawton <[email protected]> writes:
>
> I'm working on running Linux as a guest OS inside a
> lightweight cut-down plex86 environment. My goal is to
> run a stock Linux kernel, which can be slimmed down to
Wouldn't it be easier if you just compile the kernel
with a simple gcc wrapper that replaces all pushfl and popfl with your new
sequences in the assembly code generated by gcc and also in assembly files
compiled with the gcc wrapper?
I guess that would avoid much maintenance hazzle long term
-Andi
--- Andi Kleen <[email protected]> wrote:
> Kevin Lawton <[email protected]> writes:
> >
> > I'm working on running Linux as a guest OS inside a
> > lightweight cut-down plex86 environment. My goal is to
> > run a stock Linux kernel, which can be slimmed down to
>
> Wouldn't it be easier if you just compile the kernel
> with a simple gcc wrapper that replaces all pushfl and popfl with your new
> sequences in the assembly code generated by gcc and also in assembly files
> compiled with the gcc wrapper?
I'm not big on the idea of scripts massaging code - especially when
they do something unintended. It's easier to run a periodic find
script that greps for use of such instructions, if new cases
are introduced. Anyways, there were really only a few cases where
pushf/popf would have even mattered. Some stuff was just
EFLAGS.{ID/AC} identification. I greatly prefer the #define mods.
The new kernel source was quite clean of this stuff, and did a great
job centrailizing stuff in include/asm-i386.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Kevin Lawton <[email protected]> wrote:
>
> Hello all,
>
> I'm working on running Linux as a guest OS inside a
> lightweight cut-down plex86 environment. My goal is to
> run a stock Linux kernel, which can be slimmed down to
> the essentials via kernel configuration, since a guest
> OS doesn't need to drive much hardware.
>
> For this, there's a few critical but simple diffs to
> macro'ize the use of the PUSHF and POPF instructions,
> due to broken semantics of running stuff using
> PVI (protected mode virtual interrupts). The rest of
> the stuff I believe can be monitored effectively by
> the VM monitor.
>
> Would you please consider integrating these diffs before 2.6?
> There's only one new header file, and macro substitution for
> a few cases where these instructions are used. For a normal
> compile, there are zero logic changes. Just 1:1 macros.
I'm wondering if this can this be done a lot more simply with assembler
macros.
The below example generates the right code. It's then just a matter of
getting the redefined pushfl and popfl macros into kernel-wide scope.
Possibly an explicit `-include' in the makefile system.
asm("
.macro popfl
testl $(1<<9), 0(%esp)
jz 69003f
.byte 0x9d # popfl
sti
jmp 69004f
69003:
.byte 0x9d # popfl
cli
69004:
.endm
");
foo()
{
asm("popfl\n");
}
Humm, that's a good idea. I already made the mods
to files to add an #include <asm/if.h>. That would
be a logical place to stick such macros. I will
check this out and re-submit the patches if it's
workable.
Maybe this was what Andi meant too. Originally thought
he meant a script file wrapper for gcc.
Will write back soon,
-Kevin
--- Andrew Morton <[email protected]> wrote:
> I'm wondering if this can this be done a lot more simply with assembler
> macros.
>
> The below example generates the right code. It's then just a matter of
> getting the redefined pushfl and popfl macros into kernel-wide scope.
> Possibly an explicit `-include' in the makefile system.
>
>
> asm("
> .macro popfl
> testl $(1<<9), 0(%esp)
> jz 69003f
> .byte 0x9d # popfl
> sti
> jmp 69004f
> 69003:
> .byte 0x9d # popfl
> cli
> 69004:
> .endm
> ");
>
> foo()
> {
> asm("popfl\n");
> }
>
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Kevin Lawton <[email protected]> wrote:
>
> Humm, that's a good idea. I already made the mods
> to files to add an #include <asm/if.h>. That would
> be a logical place to stick such macros.
<asm/if.h> is a fine place to put the macros.
However, open-coding
#include <asm/if.h>
in the places which are known to use pushfl/popfl is fragile. Because
someone could later do something odd which results in the generation of an
unmassaged pushfl/popfl.
You need a magic bullet. Which is why I suggest including if.h via the build
system - making it truly global.
__ASSEMBLY__ and __KERNEL__ are provided via the build system as well, and
are in scope during that first inclusion. So it _should_ work....
On Wed, 22 Jan 2003, Andrew Morton wrote:
> #include <asm/if.h>
>
> in the places which are known to use pushfl/popfl is fragile. Because
> someone could later do something odd which results in the generation of an
> unmassaged pushfl/popfl.
>
> You need a magic bullet. Which is why I suggest including if.h via the build
> system - making it truly global.
>
> __ASSEMBLY__ and __KERNEL__ are provided via the build system as well, and
> are in scope during that first inclusion. So it _should_ work....
Let me just mention "gcc -include <file>". I suppose that's what you were
saying, anyway.
--Kai
OK, here's my re-submit of patches, after some great
clean-up/simplification ideas from Andrew Morton and Andi Kleen.
There are now no mods to any *.{c,S,h} files. Here's
a summary of the mods:
o Added 'Documentation/x86-hal.txt'
o Simple mods to 'Makefile'
o Added menu entry to 'arch/i386/Kconfig'
o Simple mod to 'arch/i386/boot/Makefile'
o Added 'include/asm-i386/if.h'
Only when compiling after enabling this new option,
the Makefile forces inclusion of the 'if.h' file, which
macro'izes the use of PUSHF/POPF instructions, substituting
a few lines of code which fix the broken-ness of such
logic when running with PVI (protected mode virtual interrupts).
No of this would be necessary if the VME (for vm86) semantics
were carried over to PVI.
Also, I'm including the 'Documentation/x86-hal.txt' to
state my case for getting these mods in sooner than later,
and to familiarize folks with what they're for. My bad,
not explaining it better the 1st time.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
On Wed, 22 Jan 2003, Kevin Lawton wrote:
Three minor points:
o If you included the patch inline instead of as application/octet-stream,
it'd be easier to reply ;)
> +Nothing, it's Open Source. Linux is obviously a GPL'd program.
> +Plex86 is an LGPL'd kernel module. Though it's a separate
> +
o Something's missing there?
diff -urN linux-2.5.59/Makefile linux-2.5.59-hal/Makefile
--- linux-2.5.59/Makefile Wed Jan 22 12:25:58 2003
+++ linux-2.5.59-hal/Makefile Wed Jan 22 22:36:00 2003
@@ -264,6 +264,18 @@
CFLAGS += -fomit-frame-pointer
endif
+ifdef CONFIG_X86_HAL
+# On x86, if compiling for the Hardware Abstraction Layer
+# (running Linux as a guest OS in a Virtual Machine),
+# we need to insert some asm macros which redefine
+# the behaviour of instructions which modify the
+# interrupt flag. You are probably not configuring for
+# this mode. For more info, read 'Documentation/x86-hal.txt'.
+# This needs to be the first include any module sees.
+CFLAGS += -include include/asm/if.h
+AFLAGS += -include include/asm/if.h
+endif
+
#
# INSTALL_PATH specifies where to place the updated kernel and system map
# images. Uncomment if you want to place them anywhere other than root.
@@ -409,6 +421,10 @@
# their vmlinux.lds.S file
AFLAGS_vmlinux.lds.o += -P -C -U$(ARCH)
+
+ifdef CONFIG_X86_HAL
+AFLAGS_vmlinux.lds.o += -DNO_X86_HAL_INCLUDES
+endif
arch/$(ARCH)/vmlinux.lds.s: %.s: %.S scripts FORCE
$(call if_changed_dep,as_s_S)
o These modifications should be done from arch/i386/Makefile instead,
since they're obviously i386-specific.
--- Kai Germaschewski <[email protected]> wrote:
> Three minor points:
OK, done. Here's my #3 submission. Some great
feedback from you guys. Mods are down to:
o Documentation/x86-hal.txt # added file
o include/asm-i386/if.h # added file (only used for VM)
o arch/i386/Kconfig # added one menu entry
o arch/i386/Makefile # added one ifdef..endif
o arch/i386/boot/Makefile # added one ifdef..endif
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Kevin Lawton <[email protected]> wrote:
>
> --- Kai Germaschewski <[email protected]> wrote:
>
> > Three minor points:
>
> OK, done. Here's my #3 submission.
Kinda cruel making you do all this work when Linus is unlikely to take the
patch anyway ;)
Thanks for the explanation - all is much clearer - it looks like very cool
technology.
- <asm/if.h> doesn't mean much to me. Network interface, if anything. How
about <asm/asm-macros.h> ?
- It's quite conceivable that the infrastructure will be used for other
forms of asm-mangling. Those "Q2" things hurt like hell. Is there no
other way?
- application/octet-stream!
--- Andrew Morton <[email protected]> wrote:
> Kinda cruel making you do all this work when Linus is unlikely to take the
> patch anyway ;)
If there's a misunderstanding of the potential here, of the commercial
potential, or the user-demand for these patches (which now touch
absolutely no existing *.{c,S,h} files, then I'm willing to communicate
those things to whomever needs it.
This is not a toy. The goal is not to continue modifying the kernel
or make anybody's life hard. The contrary is true - I don't want
any modifications. These are extremely simple patches to fix one
pair of broken instructions in PVI mode.
Coming from an x86 company, I'm betting Linus will get this
in a nano-second. Let's not speak for him.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
On Wed, Jan 22, 2003 at 10:23:41AM -0800, Kevin Lawton wrote:
> For this, there's a few critical but simple diffs to
> macro'ize the use of the PUSHF and POPF instructions,
> due to broken semantics of running stuff using
> PVI (protected mode virtual interrupts). The rest of
> the stuff I believe can be monitored effectively by
> the VM monitor.
Yes, what you do is nice, but generates much code. What about
this for pushfl:
pushfl
push %eax
pushfl
pop %eax
orb $(1<<1),%ah /* same as orl $(1<<9),%eax */
testl $(1<<19),%eax
jnz 69001f
andb $~(1<<1),%ah /* same as andl $~(1<<9),%eax */
69001:
mov %eax,4(%esp)
pop %eax
? This saves 6 bytes, which is a 20% code reduction ;-)
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
Ingo Oeser wrote:
> Yes, what you do is nice, but generates much code. What about
> this for pushfl:
> [11 lines of asm]
What about:
.macro pushfl
call __pushfl
.endm
.macro popfl
call __popfl
.endm
There, nice and small.
-- Jamie
--- Ingo Oeser <[email protected]> wrote:
> Yes, what you do is nice, but generates much code. What about
> this for pushfl:
Your code snipped is 10% slower. I'm not sure if it's the extra
stack activity or the 8bit user of registers (which can
pose a hazard to the execution stream on some processors).
I'm gunning for high performance.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
OK, rev#4 (and hopefully final). I only renamed a file,
as per suggestion of Andrew Morton. Haven't seen anything
else worth changing.
Quick recap of the mods involved:
o Documentation/x86-hal.txt # added file
o include/asm-i386/eflags_if.h # added file (only used for VM)
o arch/i386/Kconfig # added one menu entry
o arch/i386/Makefile # added one ifdef..endif
o arch/i386/boot/Makefile # added one ifdef..endif
Diffs are available at:
http://bochs.sourceforge.net/tmp/linux-2.5.59-hal4
The file 'Documentation/x86-hal.txt' explains the rationale for
these mods and my case for them going into the kernel before 2.6.
No *.{c,h,S} files are modified.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Hi!
> I'm working on running Linux as a guest OS inside a
> lightweight cut-down plex86 environment. My goal is to
> run a stock Linux kernel, which can be slimmed down to
> the essentials via kernel configuration, since a guest
> OS doesn't need to drive much hardware.
Can you explain a bit more about plex86? I thought plex86 aims to be
complete machine emulation, capable of running winNT (for example). I
don't think M$ will accept such a patch from you...
Or will it only increase performance when running under plex86?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
Hi!
> OK, here's my re-submit of patches, after some great
> clean-up/simplification ideas from Andrew Morton and Andi Kleen.
Please try to inline the patches, it makes it easier to comment.
How is plex86-aware-linux running under plex86 different from user
mode linux? Do you think you can make it faster?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
--- Pavel Machek <[email protected]> wrote:
> Can you explain a bit more about plex86? I thought plex86 aims to be
> complete machine emulation, capable of running winNT (for example). I
> don't think M$ will accept such a patch from you...
I gutted the old plex86 code, eliminated all the fancy stuff
and it now does nothing except provide a VM container to
run user-privilege code only. X86 is reasonably VM'able
at user priviliege, but not so at kernel privilege.
Plex86 is a kernel module which runs on the host OS. It
provides a separate set of page tables, segment registers
and other stuff so that there is no interference with the
host structures, nor dependence on them whatsover.
The thrust behind these simple mods is to be able to "push"
Linux kernel code (when running as a guest OS) down to user
level. In this case, it can also be run in what is now
an extremely light-weight VM. To do this, proper maintenance
of the interrupt flag (x86) is necessary, since behaviour of
this flag in the eflags register is different at user-level.
The x86 architecture provides a mechanism for this, called PVI
(protected mode virtual interrupts), although the logic for
this was not carried over to 2 instructions (PUSHF/POPF).
Thus my patches...
Other than that, plex86 "shadows" the guest page tables and
discovers the guest page tables on-demand. So nothing special
needs to be done. Access to system registers trap from user code,
so the VM monitor can handle those properly.
About 99% of the work of a full x86 VM is on handling less
than 1% of the cases. So the new plex86 angle is, forget doing
all the fancy work for 1%. If you're running a VM friendly OS
(like Linux with my small patches), you end up with a potentially high
performance and Open Source VM, with very little work.
As well, plex86 can bolt on to bochs for accelerating user code,
reverting back to bochs for emulation of kernel code - perhaps
good for running non-Linux, and for debugging Linux kernels.
But for the normal case of running Linux VMs, plex86 will be a standalone.
Because the non-essential IO stuff can be configured out of Linux,
and the remaining essential IO can be monitored very lightweight style
in plex86 - even right in the VM monitor for high performance.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
--- Pavel Machek <[email protected]> wrote:
> How is plex86-aware-linux running under plex86 different from user
> mode linux?
With plex86, the goal is to run the stock x86 port. Plex86 is also
x86-specific.
> Do you think you can make it faster?
To get any level of security with UML, you need to use "jailed mode"
in which performance takes a big beating. To fix this, you need
patches to Linux as a host, to make it offer a better environment
for running UML guests. From a commercial perspective, then you have
a patched Linux host + totally different port of a Linux guest.
>From a fun perspective, I think UML is fantastic achievement.
What I'm aiming for is a stock Linux host and a stock Linux guest,
the small mods to macroize PUSHF/POPF being a minor concession
to accomodate a broken PVI support in x86.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
On 2003-01-24T09:14:15,
Kevin Lawton <[email protected]> said:
> To get any level of security with UML, you need to use "jailed mode"
> in which performance takes a big beating. To fix this, you need
> patches to Linux as a host, to make it offer a better environment
> for running UML guests. From a commercial perspective, then you have
> a patched Linux host + totally different port of a Linux guest.
That commercial perspective is then completely misguided.
All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO. They
are inherently much more platform specific than UML. The necessary
modifications on the host for UML ska mode are minimal and I think besides
bashing out whether it should be a syscall, proc file or whatever, everybody
seems pretty much set on integrating them into the kernel.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
On Fri, 24 Jan 2003 08:52:46 PST, Kevin Lawton said:
> About 99% of the work of a full x86 VM is on handling less
> than 1% of the cases. So the new plex86 angle is, forget doing
> all the fancy work for 1%. If you're running a VM friendly OS
> (like Linux with my small patches), you end up with a potentially high
> performance and Open Source VM, with very little work.
One of the first implementations of VM was by IBM, called CP/67. It
eventually evolved into VM/370 and its follow-ons.
The initial design reason for CP/67 was to allow 2 or more MVS development
teams to share a system for testing, so the other team could keep working
while the first team debugged a system crash with tools better than the
lights-n-switches at the console.
It turns out that the 99% of the work to cover the 1% of the cases is really
important. The usual reason for doing VM is to isolate images from each other
- and if you don't cover that last 1%, a programming error in one of the images
can nuke your supervisor code into oblivion. It may be a "VM friendly OS like
Linux", but it can still oops in strange ways. For starters, what happens
if you run a Linux *without* your patches under plex86? ;)
Now if you think about it, and not covering the 1% case is deemed acceptable,
that's OK too. But it's something that needs to be considered.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
--- [email protected] wrote:
> It turns out that the 99% of the work to cover the 1% of the cases is really
> important. The usual reason for doing VM is to isolate images from each
> other
Plex86 can 100% isolate guests from each other. What I'm saying
is, it takes 99% of the work to do a full x86 VM which doesn't
need those 2 macros for PUSHF/POPF. (my oversimplified, but
yet useful explanation of the state of affairs)
You have to do a lot of work to "get under the hood" of an
OS, to fix up a few cases where if you let them run native,
they'll get the wrong information or make the wrong thing
happen. Not to the other guests, but to themselves. So if
you don't need to do those things, you can let them run
without all the black magic. Let's take such conversation
out-of-band. It doesn't belong on the LK list.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
On Fri, Jan 24, 2003 at 11:09:17AM -0800, Kevin Lawton wrote:
> --- [email protected] wrote:
>
> > It turns out that the 99% of the work to cover the 1% of the cases is really
> > important. The usual reason for doing VM is to isolate images from each
> > other
>
> Plex86 can 100% isolate guests from each other. What I'm saying
> is, it takes 99% of the work to do a full x86 VM which doesn't
> need those 2 macros for PUSHF/POPF. (my oversimplified, but
> yet useful explanation of the state of affairs)
>
> You have to do a lot of work to "get under the hood" of an
> OS, to fix up a few cases where if you let them run native,
> they'll get the wrong information or make the wrong thing
> happen. Not to the other guests, but to themselves. So if
> you don't need to do those things, you can let them run
> without all the black magic. Let's take such conversation
> out-of-band. It doesn't belong on the LK list.
Well actually I find it quite interesting...
One thing that seems to have been alluded to but not explicity stated
is just where is this patch going, and what affect will happen when
running a non 'VM friendly' OS under the 'new plex86'.
One thing that I'm curious about is how say thing'd work when running
a linux host, with a VM-friendly linux client, and say a Win-2k
client.
I assume that the Win-2k client woudl end up having to trap to a
simulator (bochs) for it's ring 0 stuff. But would things in the
above scenario work nicely, with proper isolation between the
two (or more) clients?
DF
--- Derek Fawcus <[email protected]> wrote:
> It doesn't belong on the LK list.
>
> Well actually I find it quite interesting...
>
> One thing that seems to have been alluded to but not explicity stated
> is just where is this patch going, and what affect will happen when
> running a non 'VM friendly' OS under the 'new plex86'.
The effect of a non VM'able guest would be it would go into the weeds.
And that effect is irrelevant to the LK list, be you interested or
not. Because that involves no particular issues of Linux as
a host nor guest, not the simple patches I submitted. Off-list, please.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
it sounds like you are saying that with the plex86 you have two ways to
load a client OS.
1. 'normal', full isolation of VMs no modification of the client OS
needed.
2. 'nice VM'. modification of the client OS required, but with the
exception of the kernel level commands being eliminated in the
modification full VM isolation is still provided. Much better performance
then case #1
if you load a client OS and tell the system that it's a #2 when it's
really a #1 then you don't have valid isolation, but that's a sysadmin
error that you will allow to happen in order to make #2 possible.
is this correct
David Lang
On Fri, 24 Jan 2003, Kevin Lawton wrote:
> Date: Fri, 24 Jan 2003 12:56:58 -0800 (PST)
> From: Kevin Lawton <[email protected]>
> To: Derek Fawcus <[email protected]>
> Cc: [email protected], Pavel Machek <[email protected]>,
> [email protected]
> Subject: Re: Simple patches for Linux as a guest OS in a plex86 VM
> (please consider)
>
>
> --- Derek Fawcus <[email protected]> wrote:
> > It doesn't belong on the LK list.
> >
> > Well actually I find it quite interesting...
> >
> > One thing that seems to have been alluded to but not explicity stated
> > is just where is this patch going, and what affect will happen when
> > running a non 'VM friendly' OS under the 'new plex86'.
>
> The effect of a non VM'able guest would be it would go into the weeds.
> And that effect is irrelevant to the LK list, be you interested or
> not. Because that involves no particular issues of Linux as
> a host nor guest, not the simple patches I submitted. Off-list, please.
>
> -Kevin
>
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--- David Lang <[email protected]> wrote:
> it sounds like you are saying that with the plex86 you have two ways to
> load a client OS.
>
> 1. 'normal', full isolation of VMs no modification of the client OS
> needed.
>
> 2. 'nice VM'. modification of the client OS required, but with the
> exception of the kernel level commands being eliminated in the
> modification full VM isolation is still provided. Much better performance
> then case #1
No, there's always full isolation. If a guest is run without
mods similar to the ones I submitted for Linux, the interrupt
behaviour will not work correctly for the guest. Neither
the host nor other guests will be affected. Nor do I care,
because this is not for running arbitrary guest OSes.
x86 does not have pure VMability. So, rather than trying real
hard to get under the hood to make it VM'able with heavy software
techniques, just forget about running all guest OSes and
run ones that can work, like Linux.
If you look, you'll notice my patches do nothing except macroize
the pushf/popf instructions to un-break the handling of eflags.IF
inside PVI mode (since x86 breaks it). This has nothing to do
with isolation of the guest OS. Nothing to do with running Windows.
Nothing to do with anything except running Linux as a guest.
-Kevin
__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com
Lars Marowsky-Bree wrote:
>All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO.
It seems plausible to expect that it might be easier to verify security
in plex86-based approaches than it is to verify security in UML.
On Sat, Jan 25, 2003 at 01:46:56AM +0000, David Wagner wrote:
> Lars Marowsky-Bree wrote:
> >All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO.
>
> It seems plausible to expect that it might be easier to verify security
> in plex86-based approaches than it is to verify security in UML.
IIRC plex86 requires quite large module on the host. And I am not sure
it's does not have any privilegies. Umlinux requires no or very minimal
(thus easy to check for insecurities) patch to kernel and does not need
any privilegies (except the helper that sets up networking, but that's
pretty minimalistic too). If you properly chroot the umlinux process,
it's very secure (the skas mode will only work in chroot once it's made
to use syscall).
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <[email protected]>
Hi!
> > To get any level of security with UML, you need to use "jailed mode"
> > in which performance takes a big beating. To fix this, you need
> > patches to Linux as a host, to make it offer a better environment
> > for running UML guests. From a commercial perspective, then you have
> > a patched Linux host + totally different port of a Linux guest.
>
> That commercial perspective is then completely misguided.
>
> All alternatives I have seen to UML (plex, vmware, UMLinux) suck
> IMHO. They
I know UML, but what is UMLinux?
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On 2003-01-26T21:00:21,
Pavel Machek <[email protected]> said:
> I know UML, but what is UMLinux?
Google, 3 seconds: http://www.umlinux.de/ :-)
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
Hello!
Why don't you take the route that Jeff Dike did with UML's skas mode?
List the patches in your site and release plex86-v2 that requires this
host patches to run.
If the results are really good lots of people will use it and you'll end
up with a number of people asking in lkml "why is the plex86-v2 patch
not available in Linus' tree?" ;)
Regards,
Nuno Silva
Hi!
> >All alternatives I have seen to UML (plex, vmware, UMLinux) suck IMHO.
>
> It seems plausible to expect that it might be easier to verify security
> in plex86-based approaches than it is to verify security in UML.
As plex86 uses pretty obscure tricks (like PVI -- is it even
documented in official Intel docs?), I doubt it is going to be easier
to verify.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?