6 ms·

Towards Secure System Graphics: Arcan and OpenBSD

63 points by beefhash 8y ago

mjg59 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
raggi 8y ago
That last sentence
- snvzz 8y ago
  Disgusting indeed. Way to make the library pointlessly Linux-specific by using epoll(), Linux NiH nonsense and actually worse than the excellent kqueue().
  - bboozzoo 8y ago
    Are you saying that upstream is actively stopping you from submitting patches adding kqueue() support or refactoring the codebase to be more portable?
    - snvzz 8y ago
      All I'm saying is that they shouldn't have relied on a linux-specific syscall in the first place. Whatever were they thinking.

63 points by beefhash 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.

raggi 8y ago

That last sentence

snvzz 8y ago
Disgusting indeed. Way to make the library pointlessly Linux-specific by using epoll(), Linux NiH nonsense and actually worse than the excellent kqueue().
- bboozzoo 8y ago
  Are you saying that upstream is actively stopping you from submitting patches adding kqueue() support or refactoring the codebase to be more portable?
  - snvzz 8y ago
    All I'm saying is that they shouldn't have relied on a linux-specific syscall in the first place. Whatever were they thinking.