On 18/12/2007, comfooc <[EMAIL PROTECTED]> wrote: > Hello, > I've found this message: > >>> On 1/22/07, Joachim Schipper <[EMAIL PROTECTED]> wrote: > >>>> OpenBSD (...) Xen is being developed (...) > >>>> Or might be ready, or might be abandoned - I'm afraid I'm not > >>>> certain here. > (...) > AFAIK after that it was silence about that topic so I want to ask what > is the current status? > > What are the problems (if they are) and possible fixes? > What need to be done? > Where are latest sources?
See: http://marc.info/?l=openbsd-misc&m=119323951310432&w=2 and: http://www.ropersonline.com/openbsd/xen/ and for the sources: http://www.ropersonline.com/openbsd/xen/openbsd-xen-howto To summarise: Status: - OpenBSD/Xen Dom U works for OpenBSD 4.1 - OpenBSD/Xen Dom 0 is not there yet. Problems: > use-after-free bugs in MI buffer-cache and filesystem code > NULL-pointer bug in uvm_pglistalloc_simple() What needs to be done: > - 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 > should be in /usr/include/uvm/, for example. Most importantly: In order for OpenBSD/Xen to get anywhere, a maintainer for the OpenBSD/Xen port would need to be found. That person would need to be *both able and willing* to look after OpenBSD/Xen and maybe even import the code into OpenBSD proper, and then maintain it. I am not that person (not able). Also, please be aware that the subject of virtualization in general (not specific to Xen) is a touchy issue on this list and has been the subject of flamewars in the past. E.g. cf. the last time OpenBSD/Xen was brought up: http://marc.info/?t=119304092900003&r=1&w=2 The reason for the controversy appears to be that it's currently en vogue in some quarters (not here) to ascribe all kinds of benefits to virtualization, including security benefits -- which are very much not really there. Virtualization introduces more complexity, complexity is the enemy of real security. The "security benefits" that virtualization introduces are mostly administrative benefits that may make it easier to determine that your boxes were pwned by a sloppy attacker, but OpenBSD people prefer their boxes to be as pwnage-proof as humanely possible, ie. to make sure their boxes don't get pwned to start with. And that's much easier to do w/o virtualization. So whatever you do, don't cite security claims as reasons for OpenBSD/Xen, unless you fancy your OpenBSD "street cred" getting rather unceremoniously shredded into little itsy bitsy pieces. Hope this helps, thanks and regards, --ropers
