login
Search
Hi all,
I know that time to time somebody do the same question, but I need to know it:
is it planned at some point to release a paravirtualized xen kernel for OpenBSD
4.3 or 4.4???
In March'08 I need to virtualize two openbsd servers under xen (host doesn't
supports HVM guests). But if it is not possible, I will migrate to NetBSD ...
Many thanks.
--
CL Martinez
carlopmart {at} gmail {d0t} com
It already exists. You can run OpenBSD DomUs (ie. run OpenBSD as a Xen "guest"**), but AFAIK you still can't run OpenBSD Dom0s (ie. run OpenBSD as a Xen "host"**). See http://www.ropersonline.com/openbsd/xen/ ** This is a flawed metaphor, because Xen is a _hypervisor_, NOT an emulator. The Domain U installs are not really running as guest OSes, and the Domain zero installations are not really running as host OSes. But you need at least one Dom0 (which when I last looked into this still could not be OpenBSD) and you can install OpenBSD as a DomU. I know very little, apart from having been curious once. If you want to know more, you probably really should talk to Christoph Egger, who did the actual porting work. Thanks and regards, --ropers
So that means that OpenBSD has code in it right now that detects if it's running under Xen and paravirtualizes itself? -Nick
Not as far as I know, but I know very little. AFAIK, it's still necessary to clone the Mercurial ( http://en.wikipedia.org/wiki/Mercurial_%28software%29 ) VCS ( http://en.wikipedia.org/wiki/Version_control_system ) as described here: http://www.ropersonline.com/openbsd/xen/openbsd-xen-howto As far as I gathered, Christoph's effort has not been widely publicised and may not even be known to even some hard core OpenBSD people. I also seemed to gather that at some point there might have been some concerns regarding running OpenBSD as a DomU or similar, because it removes some of the security benefits, so there might be a trade-off there. A DomU is not the same as a true standalone server, though I personally would welcome the incorporation of Christoph's code into OpenBSD, if only because I hope to save hosting costs and still run OpenBSD. But I could be very wrong in all of the above, and I don't want to start rumours. If you want to get proper, authoritative answers, you should probably ask Theo and Christoph (though it might benefit the archives to cc the misc list). Thanks and regards, --ropers
For what it's worth, I plan on setting up a Xen box with an Ubuntu Dom0 and an OpenBSD DomU Real Soon Now, as soon as I get my trashpile computer fixed. (It's currently running Ubuntu with faulty RAM, because I got ripped off by some US-Americans* via ebay, and I can't afford to throw more money at it to fix it, because I'm now long term ill AND on wellfare**... yadda, yadda, whine, whine ;-P ) Anyway, I plan on telling the misc list if and when I manage to set this up. Of course, dmesgs will be included. --ropers * and if you don't mind me saying it: fucking scam artist Septics. No honor or integrity. ** The Gods be praised for EU wellfare states. The Seppos don't know what they're missing. :D
no I would like to vouch for openbsd working great as a guest, but my guest has crashed a dozen times. However I think this is due to the debian linux dom0 having broken sata code for the controller in use. dom0's dmesg is filled with debug statements from sata related places in the kernel that should never be printed. We're in a messy de-centralized linux development world trying to get a stable dom0 patched together. It sucks. The paravirtualization port appears dead to me. I've tried to keep up on it, but the guy's blog no longer mentions it, his repository is often down, and when it is up the commits do not appear to be very frequent. Also his blog hasn't mentioned it in a year or more. http://hg.recoil.org/openbsd-xen-sys.hg http://anil.recoil.org/blog/
This is what I meant to hint at earlier: Running an OpenBSD DomU in connection with, say, a Linux Xen Dom0 possibly makes that OpenBSD installation subject to bugs in the hypervisor/Dom0, and that may be unavoidable. The question is, is that a worthwhile trade-off? Is this a reason not to support Xen? Or should the user be given that option regardless of the inherent limitations and consequences? --ropers
IMHO I think that OpenBSD needs to capable to install and run as a
paravirtualized domU guest, with some limitations if you like.
Last year I have do the same question. Then it was said that only needed NetBSD
do the xen port, and from there just enough to carry to OpenBSD. The reality is
that NetBSD long ago that can be installed and run as domU and OpenBSD not.
And my question is why?? i think that only one developer can't maintain this
type of code ... needs more help. I am not developer but i can do tests if you
needed ....
--
CL Martinez
carlopmart {at} gmail {d0t} com
easy: nobody has done the work. I don't know how far Christoph's efforts went really - but it really comes down to somebody sitting down, doing teh porting work in a clean manner, showing dedication, willingness and ability to keep supporting it in future. that simple. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Hi Christoph, Right now, on the OpenBSD misc mailing list, there is this discussion: http://www.sigmasoft.com/~openbsd/archives/html/openbsd-misc/2007-10/threads.html#01149 about OpenBSD/Xen. We last spoke last year, when I put your BSDtalk interview transcript online at http://ropersonline.com/openbsd/xen . It seems to me that most people on the misc mailing list currently are not very aware of your OpenBSD Xen port. Could I possibly ask you to participate in the discussion? I feel that you (and Theo) are the only guys who can provide authoritative answers on the issue. Some of the questions that I feel are unclear are: - Was your porting work fully completed? IIRC it was, but please clarify. - Is your port still being maintained? Can it be run with OpenBSD -current or 4.2? - It seems to me that your port didn't achieve wide recognition and acclaim because of a lack of publicity. - AFAIK your OpenBSD/Xen port code hasn't found its way into the official OpenBSD distribution. Is this correct? - Are there any reasons why your code didn't go into the official OpenBSD distro? Was it lack of awareness? Have you ever talked to Theo and/or other central OpenBSD people? - Is there any hope that your port might still become part of the official OpenBSD distribution? (Theo: Could you possibly comment as well?) I'd personally be very interested to see your port become part of the official distribution, but I sadly can't code myself, so all I can do is ask and hope. :) Once again, thanks for your hard work. :) Many thanks in advance and kind regards, Jens Ropers
DomU support is ready. Dom0 is work in progress.
(apart from use-after-free bugs in MI buffer-cache and filesystem code,
which damages filesystem.)
Dom0 is work in progress, but is stalling on a NULL-pointer bug
in uvm_pglistalloc_simple().
This code piece in the kernel reproduces this crash:
void foo(void)
{
struct pglist mlist;
uvm_pglistalloc(PAGE_SIZE * 64, 0, 0xffffffff, 0, 0, &mlist, 64, 0);
}
I didn't investigate further into this, because I have put my focus
on the xen-kernel and xen-tools to compile on OpenBSD and NetBSD
out-of-the-box. To finish this task, I need some things in OpenBSD:
- aio(2) support
- POSIX ptsname() (this is used in a python binding module)
- newer gcc version due to a structure padding bug with
an alignment attribute hidden in a typedef (this is fixed in gcc 3.4)
I use gcc 4.2 from the ports FYI.
- I need i386 headers and libc on OpenBSD/amd64 for 64bit builds.
gcc -m32 defines __i386__ so it is possible to distinguish if a
#include <stdint.h> must provide 32bit or 64bit integer type definitions.
Oh, a libc header cleanup is nice to have. I don't know why uvm kernel headers
can you tell me which structure? attribute packed/aligned should never be used on typedefs because of this. it's one of those astounding things that gcc compiles, but then neglects to warn that it so that userland programs can talk to the kernel. what's the problem? they're not in the way are they? (where else would they go?)
A proper Dom0 port of XEN to OpenBSD would solve this by removing the linux dependency. However this would probably require a significant effort on OpenBSD side and a XEN Hypervisor code audit. Also from earlier discussion on the list it seems this kind of virtualization may impact on security, which is in direct contrast with OpenBSD goals. Can someone elaborate more on this? ciao Luca
I might be flamed for this statement but not being able to run inside a virtualized environment is not an option in the future. Most servers you can buy today are to powerful for only taking care of one task. It is really handy to be able to "shuffle" around the cpu:s to the virtual machine that needs it at the moment. OpenBSD is much to powerful to be used only on soekris and wrap boxes as a firewall for the homeuser. If OpenBSD doesn't adopt to the virtualization trend it will used only as an obscure firewall box. If I need to run linux as Dom0 to be able to put most of my OpenBSD machines into one single box(well two actually if you want failover, and that you probably want) The security sacrifice is OK to me, at least knowing that the option is to not run OpenBSD at all since I would need too many machines and to much electricity and force me to build a new serverroom. The firewall and the KDC will probably not be virtualized yet, but everything else will soon be.
Virtualization is available already. See the package qemu. http://www.openbsd.org/4.1_packages/ Or are you aiming for Xen specifically? Keep in mind that the most significant opponent to OpenBSD has now influence if not control over Xen: http://www.theregister.co.uk/2006/07/18/ms_xen_partner/ Xen's developer and management time will be burned up with no result. No business that I am aware of has yet survived such a "partnership" It'd be a first if XenSource were to break the record. -Lars
fwiw, kvm works well too if Xen isn't a hard requirement http://kvm.qumranet.com/kvmwiki
The future is not now, no-one is saying openBSD will never run in a You know that one machine can performs more than one task even without Or perhaps future (bette) virtualizations won't require special OS support. Xen is not a be-all-end-all. --- Lars Hansson
people have been saying "if openbsd doesn't <do what i want> it will only be used as an obscure firewall box" for years. what else is new?
Virtualization seems to have a lot of security benefits. Rootkits can lie to DomU but not Dom0, and of course snapshotting, migration etc is *really* nice. Dom0 in OpenBSD in a current Xen implementation (with HVM) would be a dream. I'd switch wholesale, and buy a CD for every server (as I do now). But doubtless there are a whole host of issues, kernel, SMP, bootloaders (I found OpenBSDs bootloader to be superior to grub in Ubuntu 7.10, it detects media bay HDs, and the installer is fast, efficient, and doesn't crap out on certain video cards/monitors), an LVM, iSCSI support -- and I have no code to contribute, so I will merely remain hopeful without expectation. I tried NetBSD Xen, but it seemed the worst of both worlds. Pf circa 3.7, hacks for grub, old version of Xen (2.x series IIRC) without support for the most interesting features, not the same level of security focus, etc. So I just picked the best tool for the job. I'm happier our webservers are now on OpenBSD with CARP failover. -- "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu -----Original Message----- From: Luca Corti <luca@leenoox.net> Date: Tue, 23 Oct 2007 10:03:42 To:ropers <ropers@gmail.com> Cc:Jeff Quast <af.dingo@gmail.com>, OpenBSD-Misc <misc@openbsd.org>, Nick Guenther <kousue@gmail.com> Subject: Re: About Xen: maybe a reiterative question but .. A proper Dom0 port of XEN to OpenBSD would solve this by removing the linux dependency. However this would probably require a significant effort on OpenBSD side and a XEN Hypervisor code audit. Also from earlier discussion on the list it seems this kind of virtualization may impact on security, which is in direct contrast with OpenBSD goals. Can someone elaborate more on this? ciao Luca
> Virtualization seems to have a lot of security benefits. You've been smoking something really mind altering, and I think you should share it. x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. You've seen something on the shelf, and it has all sorts of pretty colours, and you've bought it. That's all x86 virtualization is.
Well, this post seems to get a lot of attention throughout the Internet. I normally do not participate on argumentations about opinions. However, I feel like I should get involved, as this is the field I am currently commencing my PhD research in. First, I think Theo is right when he states, that adding another layer of software doesn9t increase security. That9s what we all learned painfully in the past Chroot and jails come to mind (One has to dig deeper to find the problem) It is also true that the x86 was never designed to provide virtualization, besides, it also lacks proper separation. It wasn9t designed to be a success it just happened and we have to live with it. (This reminds me of Microsoft introducing their extension to DOS, called Windows) There are A LOT of caveats when it comes to virtualize the x86 architecture. That9s the reason why Intels VT and AMDs SVM are necessary at all. (SVM which, btw, stands for secure virtual machine - marketing is also something we have to live with, whether you believe in it or not.) It would be desirable to start over, design a new, none backwards compatible, virtualizable hardware. Best, put an extra abstraction layer on top of the hardware (put it in the BIOS or Firmware) and only deal with those interfaces. Add some crypto features et. voila. **sigh** Unfortunately, we are not living in a perfect world. So what can virtualization do for us? Speaking of paravirtualization as in the previous posts, it may add a little security in comparison to jails, but it adds a lot of convenience as handling of VMs gets easier. Which is the main selling point, so the major interest in the near future will be the handling of those virtual machines, and unfortunately not security. Security, or the way we (I/some) see it, does not sell as good as features. I have no doubt that exploiting a VM will become reality sooner or later. However, I would like to keep the discussion going, maybe in a less offensive way?! Cheers Carlo
Dear sirs please: I will return to my original question. I just wondered if xen
will be included into the OpenBSD's kernel to act as a para-virtualized DomU or
not. Nothing more. I will not go into issues of the type is insecure or not.
Theo, or somebody from developer team: Will be para-virtualized domU xen kernel
included on next OpenBSD release (4.3?) or not?? I only want to know this...
Many thanks to all.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Not unless someone actually writes the code to do it. Notice the extreme number of people with openbsd.org email addresses jumping up and down, volunteering to do it (hint: none). Possibly not even if someone writes the code. Diffs are not always merged. They should be good diffs that improve OpenBSD. Notice the number of people with openbsd.org email addresses who are not convinced that doing this a) will improve OpenBSD and b) won't actually hurt. So I'm going to guess the answer is "No, integrating xen paravirtualization is not a project priority at this time. Also, where are your diffs?" CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
Many thanks Chris. A clear response. I am not a developer but I can offer to
test xen based OpenBSD kernels on my servers ...
--
CL Martinez
carlopmart {at} gmail {d0t} com
The OpenBSD/Xen source is at http://hg.recoil.org/openbsd-xen-sys.hg Unfortunately, Anil has troubles with the availability of the server. I rely on having a willing OpenBSD developer who commits the patches I send to him. But as long as there is none, it doesn't go in. Christoph
I'm willing to stretch as far as saying: This might be interesting for some testing purposes for kernel hackers if Xen could be hosted on OpenBSD. But this doesn't mean that I'm even close to volunteering doing the job. It just would be cool to have if it doesn't break stuff. //art
Actually it is good to find NULL-pointer (mostly use-after-free) bugs, that are hard to find on real hardware. Believe me or not: OpenBSD has tons of them. Christoph
Christoph,
One question about your Xen port: is it possible to compile a xen
para-virtualized openbsd kernel to launch a clean OpenBSD 4.1 or 4.2 install??
Thanks for your great job Christoph.
--
CL Martinez
carlopmart {at} gmail {d0t} com
Seriously, what (affordable) non-x86 hardware options are available, especially those without AMT or AMT-like backdoors? http://softwarecommunity.intel.com/articles/eng/1148.htm http://www.intel.com/pressroom/archive/releases/20050301net.htm http://www.intel.com/cd/ids/developer/asmo-na/eng/320959.htm Or is workstation and server hardware covered by CALEA now, too? -Lars
I'm not sure there is a context in which Wikipedia is ever relevant: it is not now nor has ever been an authoritative source. (Look up authoritative). Lately it's become the playground for PR teams and even politicians' agendas, further reducing its accuracy. In the specific context of CALEA, the AMT wikipedia page as of Fri Oct 26 07:45:59 GMT 2007, does not contain any references to CALEA, but do contain the links I provided above. The CALEA page points to links easily found with search engines. Neither page points to non-x86 hardware options. The two points of all that grousing are 1) it's fine not to know the answer, just don't pretend to know by pointing to Google or Wikipedia, and 2) Wikipedia is not authoritative, nor in many controversial specialized cases, reliable. The question remains, what (affordable) non-x86 hardware options are available? A new question is added, are AMT-like rootkits required in all architectures, and further, is it required in closed source software? I seem to recall an anti-trust trial in the US where one company's executives said under oath something tot the effect that it would be their "patriotic duty" to put back doors into their systems if called on to do so. Regards, -Lars
CALEA requires wiretapping capabilities in networking hardware. You know that. AMT provides wiretapping capabilities, though not by name. What is unclear is how much those CALEA requirements extend to more generic computing platforms and even operating systems. AMT, from Intel's own pages, seems for all practical purposes a hard-coded rootkit useful for surveillance, among other things. Thus the connection to CALEA. So, are backdoors like AMT required for all motherboards now? If so, what are the details? If not, what non-x86 options are available for regular workstations and servers. There's a shitload available for embedded devices and such. Where are the choices for non-x86? -Lars
The only remaining alternative is Sparc. Everything else is either old (macppc) or expensive & unsupported (IA64). Best Martin
If anyone is looking for a non-x86 laptop, there aren't many choices. Is there any information about OpenBSD on the following Sparc laptop? http://www.tadpolecomputer.com/products/notebooks/viper.asp
ppc ibooks are pretty cheap, but not very upgradeable. You can get most for about $200 USD. ppc powerbooks are nice (cardbus slots, gigabit, better video cards), but more costly. You can also upgrade the cpu in old powerbooks and put big sticks of ram in them (also costly)
Perhaps some day there will be a port for the IBM Power arch. Not that I can do diddly about it. Doug.
It's too bad that Apple discontinued their PPC. It was an acceptable price, especially the mac mini. From the feedback I'm getting here it seems that the new hardware options are expensive. http://www.terrasoftsolutions.com/products/sony/ http://www.terrasoftsolutions.com/products/mercury/ http://www.tadpole.com/products/notebooks/viper.asp http://www.sun.com/servers/index.jsp?tab=2 http://www.sun.com/desktop/index.jsp?tab=0&stab=2 What else should be on the list? Regards, -Lars
It would be nice if IBM's Power stuff was, even if its older pSeries like the 7025 or 7026 yet alone anything newer. I don't know what would be involved in getting OpenBSD ported to them. Doug.
I agree that sparc64 is currently the best alternative to the x86 architecture in i386 and amd64. For me, the biggest obstacles to buying a sparc64 machine are: * sparc64 machines the are significantly more expensive than their x86 counterparts. * There is no binary emulator that would allow me to run proprietary software like Mathematica on sparc64. (In contrast, I can run Mathematica on i386 with the Linux binary emulator.) NetBSD has a Solaris binary emulator for sparc64, so with a little work it might be possible to remove this second obstacle.
On 2007 Oct 23, at 5:57 PM, adam.getchell@gmail.com wrote: > Virtualization seems to have a lot of security benefits. ``Seems'' is the key word, here. On hardware like an IBM mainframe that can acutally support what's necessary for secure virtual machines, sure. On x86? Well, it'll keep your kid sister out.... Virtualization is wonderful for simultaneously running different operating systems on the same (beefy) computer, especially for development or testing purposes. If you occassionally need to run something on an operating system other than your preferred one, it's great -- saves you the extra hardware or the reboot, lets you do snapshots, etc. For Windows, it's also wonderful. You basically have to be nuts to have a single Windows server* doing more than one thing, but virtualization lets you do exactly that with relative impunity. It's like splinting a broken leg and giving a huge shot of painkillers to the victim -- you'd never know the leg was broken. But that's about it. I suppose running Windows virtual machines on a real OpenBSD machine might ``have a lot of security benefits'' in some perverted sense of the words, but it's not like the VM is magically going to protect the virtual machines or anything. And if the Windows virtual machines can still talk to the outside world or to each other (via simulated network interfaces, for example), even those ``security benefits'' won't mean much. Cheers, b& * Yes, the full stop here is appropriate. [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
Heh. Read any of the recent advisories against vmware? Real world exploits are already out there. AIUI, to fix the current set of problems, you basically have to turn off vmware tools. Right now, you do have to attack the guest before you can get to the host, but I'm sure there's a malicious packet out there, somewhere, that can tickle the system just right, and skip past all that straight into the host. </ducks>If you do take that as the gospel truth, please, at least, buy the freaking CD, yeah? -- "This officer's men seem to follow him merely out of idle curiosity." -- Sandhurst officer cadet evaluation.
Is there any hardware inbetween that would be secure? Or, is there now nothing between the two at all? I thought that Opterons had some type of hardware support on the CPU; perhaps its only enablers not secureors. Doug.
Anil Madhavapeddy was Christoph's Google Summer of Code 2006 _mentor_. Christoph Egger did all or most of the work. Cf. here: http://code.google.com/soc/2006/xensource/about.html If people don't have Christoph's email address and want it, email me off-list. I'm not sure if it's polite to make Christoph's email address hit the archives where a thousand address harvesting bots can pick it up. OTOH, Christoph's address can be found via Google. Also, I think it's more or less useless to speculate on the state of the port -- much better to simply ask Christoph what the story is. Who knows, if there turns out to be real interest here, maybe the code can still be put to use in a way similar to what Nick suggested. --ropers
Sorry Jeff, I missed the above earlier on. Is that a yes? Does that mean that Christoph's code has gone or is going into OpenBSD current? Thanks and regards, --ropers
