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

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/

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

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

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

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. 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

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]

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.

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.

> 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.

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

Relevancy links:

http://en.wikipedia.org/wiki/Intel_Active_Management_Technology

http://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforceme...

t

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

so in the specific context of CALEA, why don't you explain how AMT is

related?

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

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

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.

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.

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 only as relevant as YOU help make it.
Shut up and improve it.
Best

   Martin

why don't you shuddup?

cu

--

    paranoic mickey       (my employers have changed but, the name has remained)

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?

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

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

cf. http://taviso.decsystem.org/virtsec.pdf

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

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.

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?

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

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

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/thr...

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?)

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