3 ms·

> privileged userspace layer BS. Either we're privileged and can copy their precious content, or they're privileged and we cannot. The current status quo is t

> privileged userspace layer BS. Either we're privileged and can copy their precious content, or they're privileged and we cannot. The current status quo is they sit above us in the truly privileged hardware modes while we are isolated, virtualized and sandboxed for their safety. It's not our computers anymore, they're just allowing us to use them.

fc417fc802 2y ago
Not what I meant. For example, on most mainstream linux distributions systemd fulfills the role of privileged userspace layer that I was referring to there. > truly privileged hardware modes The presence of a hypervisor doesn't imply paravirtualized hardware. Neither does the presence of an entire OS on modern GPUs imply a reduction in kernel responsibilities. Ring 0 is still ring 0. The OS is still managing and abstracting hardware in the same way that it always was. That doesn't mean that these other things aren't concerning developments. Particularly having an entire unauditable shadow OS running on the CPU is an incredibly dystopian scenario that almost seems unbelievable. But technical accuracy is important when discussing these things.
- matheusmoreira 2y ago
  > The OS is still managing and abstracting hardware in the same way that it always was. Not at all. The OS is not "managing" anything. It has no direct access to the real hardware. Only the firmware does. The OS is just talking to the API the firmware presents. They're not our devices anymore. They're intel's, nvidia's. They dictate how we use them. The hardware's just sitting there, waiting for the right electrical signals to come in. But the OS is not the one sending those signals. Their firmware's in charge of that. It's the middle man between the OS and the device we paid money for. If the firmware doesn't like the tune we're singing, it shuts us down. There are completely separate computers inside these things. They don't run our code, they only run signed code. Whoever has the keys to the machine's code owns the machine itself. And it sure as hell ain't us.
  - fc417fc802 2y ago
    "Managing" and "talking to an API" are not mutually exclusive though. Yes, firmware has continuously become more complex. Yes, if you go back far enough (quite a long ways) there wasn't any. Peripherals have always been a black box that increased in complexity over time. That increase in complexity does not imply a decrease in management complexity on the part of the kernel. Far from it! Modern device drivers are far from simple. > They're not our devices anymore. They're intel's, nvidia's. This is arguably true, but it is also a rather separate topic of discussion. > They dictate how we use them. That's largely only in theory. Now if you had said that Apple or Samsung were dictating how we use our phones I would have been inclined to agree. But I don't think gating certain features in the CPU or GPU for the purpose of market segmentation qualifies as dictating how I use my device. I don't like the practice, but I can't deny that I am able to use the APIs provided by the device in an arbitrary manner without it phoning home to the manufacturer or otherwise authorizing the specifics of their use. > But the OS is not the one sending those signals. Depending on how you define "sending those signals" and where you consider the boundary between sender and receiver to be you could reasonably argue that the OS never did that to begin with, or alternatively that it has always done so and still does. It's really quite arbitrary and depends entirely on where you consider the boundary of the device to lie. I purchase a peripheral. It is a black box that implements some device or manufacturer specific API. The kernel has a device driver that abstracts over this and provides a generic userspace API that will (hopefully) remain relatively stable for multiple decades. That's the extent of the contract and that hasn't changed at all. The device driver situation is already nearly unmanageable. Imagine how much worse it would be if the kernel needed to manage every last minute hardware detail down to the model and even sub-model variants. For example, for every USB mouse and keyboard, past and present. And that's before we even consider things like the firmware for the USB controller on the mouse, which in all likelihood is its own modularized unit from an entirely different manufacturer. But we're going to need to account for every last detail of that ourselves if we fully commit to the "all opaque firmware bad" route. After all, for the kernel to "truly" be in control of the hardware I suppose it will need to manually manage every last pin that falls under software control. Technical accuracy and nuance is really quite important here. There are many different nefarious things happening at once. Conflating them only serves to confuse the discussion and leads people to (wrongly) believe that there's no need to worry about those weirdos ranting and raving in the corner.
- dr-detroit 2y ago
  [dead]

fc417fc802 2y ago

Not what I meant. For example, on most mainstream linux distributions systemd fulfills the role of privileged userspace layer that I was referring to there. > truly privileged hardware modes The presence of a hypervisor doesn't imply paravirtualized hardware. Neither does the presence of an entire OS on modern GPUs imply a reduction in kernel responsibilities. Ring 0 is still ring 0. The OS is still managing and abstracting hardware in the same way that it always was. That doesn't mean that these other things aren't concerning developments. Particularly having an entire unauditable shadow OS running on the CPU is an incredibly dystopian scenario that almost seems unbelievable. But technical accuracy is important when discussing these things.

matheusmoreira 2y ago
> The OS is still managing and abstracting hardware in the same way that it always was. Not at all. The OS is not "managing" anything. It has no direct access to the real hardware. Only the firmware does. The OS is just talking to the API the firmware presents. They're not our devices anymore. They're intel's, nvidia's. They dictate how we use them. The hardware's just sitting there, waiting for the right electrical signals to come in. But the OS is not the one sending those signals. Their firmware's in charge of that. It's the middle man between the OS and the device we paid money for. If the firmware doesn't like the tune we're singing, it shuts us down. There are completely separate computers inside these things. They don't run our code, they only run signed code. Whoever has the keys to the machine's code owns the machine itself. And it sure as hell ain't us.
- fc417fc802 2y ago
  "Managing" and "talking to an API" are not mutually exclusive though. Yes, firmware has continuously become more complex. Yes, if you go back far enough (quite a long ways) there wasn't any. Peripherals have always been a black box that increased in complexity over time. That increase in complexity does not imply a decrease in management complexity on the part of the kernel. Far from it! Modern device drivers are far from simple. > They're not our devices anymore. They're intel's, nvidia's. This is arguably true, but it is also a rather separate topic of discussion. > They dictate how we use them. That's largely only in theory. Now if you had said that Apple or Samsung were dictating how we use our phones I would have been inclined to agree. But I don't think gating certain features in the CPU or GPU for the purpose of market segmentation qualifies as dictating how I use my device. I don't like the practice, but I can't deny that I am able to use the APIs provided by the device in an arbitrary manner without it phoning home to the manufacturer or otherwise authorizing the specifics of their use. > But the OS is not the one sending those signals. Depending on how you define "sending those signals" and where you consider the boundary between sender and receiver to be you could reasonably argue that the OS never did that to begin with, or alternatively that it has always done so and still does. It's really quite arbitrary and depends entirely on where you consider the boundary of the device to lie. I purchase a peripheral. It is a black box that implements some device or manufacturer specific API. The kernel has a device driver that abstracts over this and provides a generic userspace API that will (hopefully) remain relatively stable for multiple decades. That's the extent of the contract and that hasn't changed at all. The device driver situation is already nearly unmanageable. Imagine how much worse it would be if the kernel needed to manage every last minute hardware detail down to the model and even sub-model variants. For example, for every USB mouse and keyboard, past and present. And that's before we even consider things like the firmware for the USB controller on the mouse, which in all likelihood is its own modularized unit from an entirely different manufacturer. But we're going to need to account for every last detail of that ourselves if we fully commit to the "all opaque firmware bad" route. After all, for the kernel to "truly" be in control of the hardware I suppose it will need to manually manage every last pin that falls under software control. Technical accuracy and nuance is really quite important here. There are many different nefarious things happening at once. Conflating them only serves to confuse the discussion and leads people to (wrongly) believe that there's no need to worry about those weirdos ranting and raving in the corner.
dr-detroit 2y ago
[dead]