Running XLibre on OpenBSD manually

[cepelinas9000]

Installing XLibre on OpenBSD (manually step-by-step)

0. Preface

• XServer will run as root and with VESA driver
• You need /usr/X11R6 (Xenocara) installed first - there are tools, fonts, default settings and so on (technically you can make XLibre prefix=/usr/X11R6 to replace most files)
• The Xenocara privilege separation can be summed with (correct me if I wrong) : 1) Start Xorg as root and perform strictly necessary operations as root 2) Switch Xorg process to unprivileged user 3) All operations requiring root (mainly opening nodes in /dev/*) are done via rpc (Xenocara performs fork - root part start small rpc server, user part [rest of Xserver] open files via rpc). See: https://github.com/openbsd/xenocara/blob/53708eac2870ad3017b2a741dfad0a1cf1846640/xserver/os/privsep.c#L76 and https://github.com/openbsd/xenocara/blob/53708eac2870ad3017b2a741dfad0a1cf1846640/xserver/os/privsep.c#L260
• Not everything rosy - mainly from necessity specific bits around kernel and supporting libraries ABI - At a glance mainly due older interfaces (especially kms)
• There is additional patches for VESA drivers - unexported xf86SlowBcopy and OpenBSD specfific bit
• For input I used https://github.com/X11Libre/xf86-input-keyboard and https://github.com/X11Libre/xf86-input-mouse
• watch for autotools versions

1a. additional patch (for xserver)

patch-for-xserver.patch

diff --git a/hw/xfree86/os-support/bsd/i386_video.c b/hw/xfree86/os-support/bsd/i386_video.c
index 267e4f5..f7201a8 100644
--- a/hw/xfree86/os-support/bsd/i386_video.c
+++ b/hw/xfree86/os-support/bsd/i386_video.c
@@ -150,6 +150,7 @@ xf86OSInitVidMem(VidMemInfoPtr pVidMem)
     checkDevMem(TRUE);
 
     pci_system_init_dev_mem(devMemFd);
+    pci_legacy_open_io(NULL, 0, 64*1024);
 
     pVidMem->initialised = TRUE;
 }

1b. additional patch (for vesa driver, alternatively XServer can export this symbol)
patch-for-vesa.patch

diff --git a/src/vesa.c b/src/vesa.c
index 1e69f4d..00658bc 100644
--- a/src/vesa.c
+++ b/src/vesa.c
@@ -64,6 +64,16 @@
 #endif
 #include "compat-api.h"
 
+// took from hw/xfree86/os-support/misc/SlowBcopy.c
+/* The outb() isn't needed on my machine, but who knows ... -- ost */
+void
+xf86SlowBcopy(unsigned char *src, unsigned char *dst, int len)
+{
+    while (len--)
+        *dst++ = *src++;
+}
+
+
 /* Mandatory functions */
 static const OptionInfoRec * VESAAvailableOptions(int chipid, int busid);
 static void VESAIdentify(int flags);

2. Install requirements and download build tools

# mkdir -p /home/xlibre
# cd /home/xlibre
# export LIBRE_PREFIX=/usr/local/xlibre
# export LIBRE_LOGS=/var/log


# pkg_add git meson cmake git autoreconf automake libtool epoll-shim
# export AUTOCONF_VERSION=2.72
# export AUTOMAKE_VERSION=1.17
# git clone --depth 2 https://github.com/X11Libre/xserver.git
# git clone --depth 2 https://github.com/X11Libre/xf86-input-keyboard.git
# git clone --depth 2 https://github.com/X11Libre/xf86-input-mouse.git
# git clone --depth 2 https://github.com/X11Libre/xf86-video-vesa.git

3. Install Xserver

# cd xserver
# patch -p1 < ../patch-for-xserver.patch
# meson build -Dprefix=$LIBRE_PREFIX -Dlog_dir=$LIBRE_LOGS -Dudev=false -Dudev_kms=false
# cd build
# ninja install

4. Install drivers

# export  PKG_CONFIG_PATH=/usr/local/xlibre/lib/pkgconfig

# cd /home/xlibre/xf86-input-keyboard
# autoreconf -v --install -I/usr/X11R6/share/aclocal -I/usr/local/xlibre/share/aclocal  
# ./configure --prefix=$LIBRE_PREFIX && make install

# cd /home/xlibre/xf86-input-mouse
# autoreconf -v --install -I/usr/X11R6/share/aclocal -I/usr/local/xlibre/share/aclocal  
# ./configure --prefix=$LIBRE_PREFIX && make install

# cd /home/xlibre/xf86-video-vesa
# patch -p1 < ../patch-for-vesa.patch
# autoreconf -v --install -I/usr/X11R6/share/aclocal -I/usr/local/xlibre/share/aclocal  
# ./configure --prefix=$LIBRE_PREFIX && make install

5. set to use mouse driver for mouse

cat >/usr/local/xlibre/share/X11/xorg.conf.d/20-mouse.conf <<EOF
Section "InputClass"
  Identifier "ForMouse"
  MatchIsPointer "on"
  Driver "mouse"
EndSection
EOF 

6. Tell xenodb to use Xlibre server (openbsd specific) :

# sed -i 's/X11R6/local\/xlibre/' /etc/X11/xenodm/Xservers

# /etc/rc.d/xenodm restart
 

p.s. I'm totally novice OpenBSD user

[stefan11111]

@metux why do we have xf86SlowBcopy defined like that instead of memcpy?

[metux]

@metux why do we have xf86SlowBcopy defined like that instead of memcpy?

IIRC this was a hack for some really old buses where normal memcpy was just too fast (the HW engineers forgot to inject wait states)
No idea whether those HW still exists.

[stefan11111]

If that's still desired, we should make dst and src volatile, so the compiler can't optimize anything.

If not, we should replace that by memcpy.

[callmetango]

A feedback from Andrath (@Andrath1975) / X in Andrath on X: "@XLibreDev That's nice, but ..." / X:

That's nice, but it's really not usable yet:

• only vesa driver
• runs as root (bad)

It's a great start though! I mentioned it on the OpenBSD misc@ list.

[callmetango]

Replied in (2) XLibre on X: "@Andrath1975 Thank you for mentioning..." / X:

Thank you for mentioning #XLibre on the #OpenBSD misc@ list! Yes, so far it is a proof of concept and deserves more work. Yet it is also to show our interest in OpenBSD and a call for contributors. Tomorrow we will announce one more thing underlining our commitment to the #BSD s.

[stefan11111]

That's nice, but it's really not usable yet:

* only vesa driver

Surely fbdev also works, no?

vesa only works on x86.
On linux, it conflicts with kms. Maybe it also has such problems on openbsd.

Both vesa and fbdev are unaccelerated, do we now have any accelerated drivers working on openbsd?

[b-aaz]

fbdev is For Linux, OpenBSD and NetBSD use wsfb.
FreeBSD and DragonFlyBSD use scfb.

[callmetango]

@cepelinas9000 Thank you very much for the first steps of XLibre on OpenBSD and documenting them and your thoughts!

I thought about the Xenocara privilege separation as you described it in:

The Xenocara privilege separation can be summed with (correct me if I wrong) : 1) Start Xorg as root and perform strictly necessary operations as root 2) Switch Xorg process to unprivileged user 3) All operations requiring root (mainly opening nodes in /dev/*) are done via rpc (Xenocara performs fork - root part start small rpc server, user part [rest of Xserver] open files via rpc).

when Andrath said "runs as root (bad)" and I had an idea:

Can't we have a look at what Xenocara does regarding this privilege separation in detail and eventually upstream the patches? Running the Xserver as root (uid 0) has often enough been critized and wouldn't it be time to address this? I cannot assess the technical implications, but from a feature and security standpoint it could be appealing, no?

@metux What do think?

[ekollof]

You will find all the information on how Xenocara differs from Xorg and why it is a fork (albeit a soft one) here:

https://xenocara.org/

[cepelinas9000]

when Andrath said "runs as root (bad)" and I had an idea:

This one can be universally solved with small os specific patch (pledge thingy) and integration libseat to OpenBSD (https://github.com/kennylevinsen/seatd).

[ekollof]

It should be able to work without a seat daemon. Also, Xenocara is mostly about the build infrastructure as well. Privsep is not the only thing.

[callmetango]

A feedback from Joel Carnat ♑ 🤪 (@joel@tumfatig.net) - Mastodon in Joel Carnat ♑ 🤪: "@XLibreDev which leads to 2 qu…" - Mastodon:

which leads to 2 questions:
-1- are there any performance differences?
-2- do you plan on integrating the diffs that made them fork from Xorg?
-2bis- if that even makes sense :)

[callmetango]

Replied in XLibre: "@joel Thank you for your quest…" - Mastodon:

Thank you for your questions! We forwarded them to https://github.com/orgs/X11Libre/discussions/346 .

In general we merge distribution specific patches if they are of general interest. The OpenBSD https://xenocara.org/ consists of at least the ability to run the X server without root privileges and a custom build system. We will take a look at this and evaluate the extent to which we can integrate these changes.

As far as the performance is concerned, we have not yet taken any measurements on bare metal.

[josephcrowell]

As a member of the team, I have one burning question.

Why are we working separately from them when we could be pooling our resources?

[metux]

As a member of the team, I have one burning question.

Why are we working separately from them when we could be pooling our resources?

Of course a direct collaboration would be better. We should reach out to them an talk about it.
@callmetango would you like to do this ?

OTOH, we can always work on upstreaming their patches independently.

[stefan11111]

@metux I don't think it makes sense to upstream most of the xenocara patches.
From my knowledge, most of the patches are build-system related and only make sense on openbsd, or are for taking advantage of bsd-only kernel api to make the X server use less privileges.

[callmetango]

As I understand it, @cepelinas9000 simply wanted to find out whether XLibre can run on OpenBSD. This proof of concept was successful and was mentioned in the social media campaign “XLibre Week of the BSDs.” It should be noted that this test took place in a virtual machine and not in a bare metal environment. As far as I know, nothing more has happened so far.

I am in favor of talking to the Xenocara developers once we know what we want to talk about.

At the moment, it is unclear which of the Xenocara changes are distribution-specific and which can be used universally for the XLibre project. That is exactly what we should find out first. As @stefan11111 mentioned, some things may be very distribution-specific. Likewise, we should first release version 25.1.0, as our current version 25.0.0.x has been publicly designated as beta by ourselves.

After that, I will be happy to contact the Xenocara developers.

[bugcrazy]

Contact OpenBSD devs to contribute to security and new features in X11. A good way would be to talk on their tech list: tech@openbsd.org

[callmetango]

Please see my comment #24 (reply in thread).

[stefan11111]

1a. additional patch (for xserver)

patch-for-xserver.patch

diff --git a/hw/xfree86/os-support/bsd/i386_video.c b/hw/xfree86/os-support/bsd/i386_video.c
index 267e4f5..f7201a8 100644
--- a/hw/xfree86/os-support/bsd/i386_video.c
+++ b/hw/xfree86/os-support/bsd/i386_video.c
@@ -150,6 +150,7 @@ xf86OSInitVidMem(VidMemInfoPtr pVidMem)
     checkDevMem(TRUE);
 
     pci_system_init_dev_mem(devMemFd);
+    pci_legacy_open_io(NULL, 0, 64*1024);
 
     pVidMem->initialised = TRUE;
 }

@metux @cepelinas9000 @b-aaz
Is this patch also useful for other bsd's?
Should this be upstreamed?

1b. additional patch (for vesa driver, alternatively XServer can export this symbol) patch-for-vesa.patch

diff --git a/src/vesa.c b/src/vesa.c
index 1e69f4d..00658bc 100644
--- a/src/vesa.c
+++ b/src/vesa.c
@@ -64,6 +64,16 @@
 #endif
 #include "compat-api.h"
 
+// took from hw/xfree86/os-support/misc/SlowBcopy.c
+/* The outb() isn't needed on my machine, but who knows ... -- ost */
+void
+xf86SlowBcopy(unsigned char *src, unsigned char *dst, int len)
+{
+    while (len--)
+        *dst++ = *src++;
+}
+
+
 /* Mandatory functions */
 static const OptionInfoRec * VESAAvailableOptions(int chipid, int busid);
 static void VESAIdentify(int flags);

This doesn't look right.
The vesa driver doesn't use this function.
Are you using some other patches for the vesa driver that depend on this symbol?

[cepelinas9000]

pci_legacy_open_io(NULL, 0, 64*1024); - as I understand is openbsd specific (or even due to pciaccess library)

vesa driver uses slowbcopy_frombus and slowbcopy_tobus, which are defined as macros, see: https://github.com/X11Libre/xserver/blob/4b54da3fc6068c128bc4e3b7ba18703af25a251b/hw/xfree86/common/compiler.h#L1029

correct fix is to define in vesa, xf86-video-mga , xf86-video-sis drivers (these uses that slowbcopy function), other fix is with memcpy but it need to be somehow tested on real hardware to avoid surprises.

[stefan11111]

pci_legacy_open_io(NULL, 0, 64*1024); - as I understand is openbsd specific (or even due to pciaccess library)

Maybe we should add it behind #ifdef OpenBSD?

vesa driver uses slowbcopy_frombus and slowbcopy_tobus, which are defined as macros, see: https://github.com/X11Libre/xserver/blob/4b54da3fc6068c128bc4e3b7ba18703af25a251b/hw/xfree86/common/compiler.h#L1029

correct fix is to define in vesa, xf86-video-mga , xf86-video-sis drivers (these uses that slowbcopy function), other fix is with memcpy but it need to be somehow tested on real hardware to avoid surprises.

Found it.

xf86SlowBcopy is exported though, how come this doesn't work on openbsd?
https://github.com/X11Libre/xserver/blob/4b54da3fc6068c128bc4e3b7ba18703af25a251b/hw/xfree86/os-support/xf86_OSproc.h#L108

@metux @b-aaz Any idea why this breaks on openbsd?

[cepelinas9000]

Maybe we should add it behind #ifdef OpenBSD?

Probably we should do that.

for slowbcopy reason simple, it is not compiled: https://github.com/X11Libre/xserver/blob/4b54da3fc6068c128bc4e3b7ba18703af25a251b/hw/xfree86/os-support/meson.build#L37

@b-aaz solved by adding misc/SlowBcopy.c to bsd target: https://github.com/b-aaz/xlibre-ports/blob/master/x11-servers/xlibre-server/files/patch-hw_xfree86_os-support_meson.build

[b-aaz]

About SlowBcopy, I am very skeptical of its functionality, VESA depends on it but using any moderately modern compiler, xf86SlowBcopy() in its current form compiles down to memcpy completely defeating its purpose.
I'm unsure if it is needed anymore on any new hardware, and I do not know what platforms/cards needed it in the past.
Furthermore this function was in this shape for 18 years and we can guess that after the roll out of the above mentioned optimization in major compilers this function was effectively compiled as memcpy for around a decade.

This thread is interesting regarding this topic:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202643
It seams like we need this function for backward compatibility with some old hardware and we need it to function as intended, copying a single byte at a time.

[stefan11111]

@b-aaz solved by adding misc/SlowBcopy.c to bsd target: https://github.com/b-aaz/xlibre-ports/blob/master/x11-servers/xlibre-server/files/patch-hw_xfree86_os-support_meson.build

@metux Perhaps we should always build this file?
I don't see anything that would break on non-linux.