Earlier quoted context omitted.
>4k To be pedantic, OP specified "HD" which is 720p. I gave him benefit of the doubt by saying "high resolution" in my reply, but I think 4K is unreasonable given the provided context. I'd wager 1080p ("Full HD") at most. There's also the question of frame rate, though we can probably safely assume either 29.976 or 59.952 fps since it's Youtube. As an aside, software decoding performance can vary pretty significantly…
Correction: I think I experienced noticeable stutters with Full HD videos not with HD videos.
Qubes OS: A reasonably secure operating system
111–118 of 118 posts
Re: Qubes OS: A reasonably secure operating system
#112Earlier quoted context omitted.
Isn't it reasonable for applications to assume that, now that virtually all hardware has it, even super-cheap computers like the Raspberry Pi?
I understand GPUs are a security nightmare. If you want to have some understanding of your security, don't use a GPU.
Yeah, if you really care about security, only use computer which use line printers as output mechanisms.
Re: Qubes OS: A reasonably secure operating system
#113Earlier quoted context omitted.
Pi 1-3 https://docs.mesa3d.org/drivers/vc4.html Pi 4-5 https://docs.mesa3d.org/drivers/v3d.html
> Broadcom never released a public specification for the V3D 3.x or 4.x series. So the support must be worse if you prefer free drivers?
No, as there isn't a non-free driver alternative to compare V3D to. For VC4 (Pi 1-3) there was a proprietary alternative driver... but it was a bit garbage.
It feels you may be conflating the "proprietary firmware blob on the GPU which is used to boot the Pi" story with the GPU driver itself.
Re: Qubes OS: A reasonably secure operating system
#114Earlier quoted context omitted.
> Broadcom never released a public specification for the V3D 3.x or 4.x series. So the support must be worse if you prefer free drivers?
No, as there isn't a non-free driver alternative to compare V3D to. For VC4 (Pi 1-3) there was a proprietary alternative driver... but it was a bit garbage. It feels you may be conflating the "proprietary firmware blob on the GPU which is used to boot the Pi" story with the GPU driver itself.
Yes, you are right, "proprietary firmware blob on the GPU which is used to boot the Pi" is what I recall as a big Pi problem. So my original wording is correct that you need proprietary blobs to run Raspberry Pi, isn't it?
Re: Qubes OS: A reasonably secure operating system
#115Earlier quoted context omitted.
No, as there isn't a non-free driver alternative to compare V3D to. For VC4 (Pi 1-3) there was a proprietary alternative driver... but it was a bit garbage. It feels you may be conflating the "proprietary firmware blob on the GPU which is used to boot the Pi" story with the GPU driver itself.
Yes, you are right, "proprietary firmware blob on the GPU which is used to boot the Pi" is what I recall as a big Pi problem. So my original wording is correct that you need proprietary blobs to run Raspberry Pi, isn't it?
"Yes" in that the above statement about needing proprietary blobs to boot the Pis is certainly accurate & true (ongoing science experiments notwithstanding). "No" in that we somehow went from talking about "how apps can safely assume to rely on accelerated rasterization instead of software rasterization" to "how the Raspberry Pi family needs proprietary boot firmware to do anything with app output at all" and I've missed the connection between the two points.
Re: Qubes OS: A reasonably secure operating system
#116Earlier quoted context omitted.
The issue for Qubes is security. GPUs can be used to subvert basically all the otherwise hardware-enforced security protections.
In a desktop, couldn't you assign a GPU to one video machine and in that scenario would there still be a security problem when there is only one VM using it?
Yes, this is what qubes would probably suggest as the solution.
Re: Qubes OS: A reasonably secure operating system
#117Earlier quoted context omitted.
Yes, you are right, "proprietary firmware blob on the GPU which is used to boot the Pi" is what I recall as a big Pi problem. So my original wording is correct that you need proprietary blobs to run Raspberry Pi, isn't it?
"Yes" in that the above statement about needing proprietary blobs to boot the Pis is certainly accurate & true (ongoing science experiments notwithstanding). "No" in that we somehow went from talking about "how apps can safely assume to rely on accelerated rasterization instead of software rasterization" to "how the Raspberry Pi family needs proprietary boot firmware to do anything with app output at all" and I've mi…
> support must be worse if you prefer free drivers
Re: Qubes OS: A reasonably secure operating system
#118Earlier quoted context omitted.
I would personally have chalked that up as usability-- because there are facilities for secure file transfer between computers, but I get the argument. Particularly since the common tools like SCP give way too much access unless you go through special effort. > Floppy disks, Hard disks As you note there are 'auto run' like issues, also file systems are not historically very robust against against malicious data. Hard…
Was there ever a case in the wild of malware being installed into a host by inserting a floppy disk, without entailing the user boot off it, run a program from it, open a datafile crafted to exploit existing software, etc? I always thought if you insert a floppy (with any OS autorun crap turned off of course), open a textfile to read, then take it out, you'd be pretty safe. (It's unfortunate the same can't be said of…
It's been a decade but I have previously fuzzed multiple linux file system implementations and was able panic the kernel. I would be somewhat surprised if none had code execution vulnerabilities at some point, but I can't think of any publicly known ones off the top of my head.
Of course there absolutely have been auto-run vulnerabilities too. And modern Linux desktops have more auto-running auto-indexing stuff than ever. I've absolutely seen mounted drives being eagerly explore by gnome thumbnail generation stuff and likewise.
The challenge for modern security isn't avoiding vulnerabilities, it's avoiding whole classes of behavior that might be vulnerable because the attack surfaces are so huge that we'll inevitably miss vulnerabilities so long as they're not structurally impossible.
So for example, I'd always prefer to interact with a potentially malicious file system via an ephemeral read-only VM that reads the files and exports a network-fs like interface to my working system... It's just too hard to be certain there are no filesystem vulnerabilities-- they have huge surfaces and they're not usually tested against that. I can't even be sure latest genius systemd feature doesn't silently run stuff on removable media (just as it did stuff like given unprivleged users the ability to modify the system time without clearly documenting the change), if it's allowed to touch it. And if there issues are I'll be thankful that the malware payload would have also had to contain a VM escape for it to compromise my system.