
Towards Secure System Graphics: Arcan and OpenBSD - beefhash
https://arcan-fe.com/2018/04/25/towards-secure-system-graphics-arcan-and-openbsd/
======
mjg59
It's true that a bunch of the Linux infrastructure for handling things is more
painful than the equivalent OpenBSD infrastructure - the thing that's ignored
here is that a bunch of the reason for the difference in complexity is that
OpenBSD isn't trying to solve as many problems. Picking the backlight case
since it's one I'm familiar with[1] - there are three different broad ways
that a backlight can be presented to the OS. There's the standard ACPI
mechanism, which can be loosely associated with a display under a limited
number of circumstances. There's platform-specific mechanisms, which usually
can't be meaningfully associated with a display. Finally, there's backlight
control that's handled through the GPU directly.

Where the GPU has backlight control registers, these will usually work and so
there's an incentive to always use them - except for systems where the
firmware expects to be able to drive the backlight (for instance, cases where
hitting the backlight control buttons triggers system management interrupts
that then cause the firmware to write to the same registers, or firmware-
controlled ambient light sensors), which then results in the hardware state
and the firmware state being out of sync and the brightness jumping about in
an unpredictable way. And even on systems where using the GPU registers _is_
the right thing to do, one dual-GPU systems where the iGPU is hooked up to the
screen then you need to use its backlight control registers even if you're
rendering on the dGPU. And on dual-GPU Apples, you need to ignore the GPU
registers because the backlight is controlled by the gmux and hitting the GPU
registers can fuck things up in amazingly hilarious ways.

If you ignore all these problems then you end up with a simpler interface, and
it probably works for a decent percentage of use cases. The same applies to
input (things like libratbag exist to apply a level of abstraction to more
complicated mouse-style input devices, which you can ignore if you don't
care), and to a whole bunch of things if you don't need to care about
multiseat.

(The discussion about security doesn't match my experience of working with the
Linux graphics community - patches and even new drivers have been rejected
based on their security impact, even if they add new functionality)

[1] I wrote libbacklight

~~~
mjg59
Having dug through the OpenBSD source code - it looks like backlight control
on x86 will only work if you have either:

1) Working generic ACPI backlight control 2) A Thinkpad 3) A Toshiba 4) An
Intel GPU

Further, in the case where your machine satisfies more than one of these,
you'll end up using whichever one attached last with no way for userland to
override it. So, yeah, easier to use but failing to solve a bunch of the
complexity as a result.

~~~
notaplumber
To be more specific, which ever attaches first. Firmware controls (ACPI) are
favoured over the native hardware controls (drm).

[https://marc.info/?l=openbsd-
cvs&m=149989034626478&w=2](https://marc.info/?l=openbsd-
cvs&m=149989034626478&w=2)

On OpenBSD, RandR xbacklight(1) often just works out of the box, and as the
author of the article writes, involves much less magic than the rituals
involving systemd on Linux.

Perhaps your Linux bias is showing little as you attempt to justify the
complexity of the interfaces Linux provides.. care to go for a round on
epoll(2), a botched attempt at copying kqueue(2)? Or how about getrandom(2), a
Linux kitchen sink that sprung out of OpenBSD getentropy(2).

~~~
mjg59
If acpivideoout and thinkpad both attach then whichever attaches second will
win - you're right that i915 special cases this. The author of the article
describes doing an ioctl() on the console, which is a different codepath to
any brightness properties attached to the connector, so if the OpenBSD DRM
implementation is exposing the latter on chipsets other than i915 then you're
still going to have two different codepaths to get broader coverage (and it's
still broken on Apples)

I'm not interested in defending Linux in general, I'm just pushing back
against the idea that a low complexity implementation is inherently preferable
to a more complex one. _All else being equal_ that's true, but if the
additional complexity is associated with additional useful functionality then
it's really up to the person making that claim to demonstrate that a less
complex implementation could provide the same functionality or to make it
clear that they're ok with not satisfying the use cases that require that
functionality.

~~~
hedora
The article is arguing for a low complexity _API_. The complexity of an
interface is only loosely coupled to the complexity of the implementation.

The article even hints at a better solution than what Linux or OpenBSD do: Add
backlight control in a away that provides 1:1 (or 1:0) mapping between display
devices and backlights by, for example, adding the backlight API to the
display device file. A naming convention for device files would also work. So
would a directory of device files associated with a given screen.

You could even have a device file that lets you tell the kernel if it should
use ACPI or something else, assuming you don’t like the default.

What doesn’t work is the status quo in Linux, where there’s a 50% chance I
have to implement a new shell script that futzes with some one-off device file
in /sys every time I buy a new laptop. (And then use xbindkeys, or whatever to
make the keyboard shortcut work)

Fixing this would require the type of thankless work that never quite gets
done in the Linux kernel.

I suspect it is because no one has a financial motivation to fix things like
this, but they do have a financial motivation to bring up new hardware and to
strong-arm through platform lock in plays like systemd.

edit: and thank you for libbacklight. It works beautifully on the other
laptops. :-)

~~~
mjg59
The biggest problem is that the policy association between what the hardware
and firmware provide and what the expected behaviour is vary between releases
of Windows, and so having the kernel make that kind of association leads to
problems. The goal of doing stuff with a userland library was to leave the
mechanism up to the kernel (ie, expose the various different ways of driving
the hardware) and allow userland to make a policy decision over which
interface was least likely to cause confusion.

If you're having to write shell scripts then there's absolutely a failure -
but I haven't bought a laptop in years where that's been the case (and I
stopped doing this stuff professionally a few years ago, so I really do
appreciate stuff working out of the box). Desktop environments should be
providing the necessary glue to bind keys to something that can make an
appropriate decision while still allowing overrides for the corner cases that
the kernel can't catch.

Systemd actually makes it easier to handle a lot of these -it provides a
centralised mechanism for exposing platform-specific quirks to other userland
components. I'm not going defend every systemd design decision, but honestly
it's been an improvement for everything discussed in this post.

------
raggi
That last sentence

~~~
snvzz
Disgusting indeed. Way to make the library pointlessly Linux-specific by using
epoll(), Linux NiH nonsense and actually worse than the excellent kqueue().

~~~
bboozzoo
Are you saying that upstream is actively stopping you from submitting patches
adding kqueue() support or refactoring the codebase to be more portable?

~~~
snvzz
All I'm saying is that they shouldn't have relied on a linux-specific syscall
in the first place. Whatever were they thinking.

