Earlier quoted context omitted.
libreboot is dead. There hasn't been any new hardware in more than a decade.
ok coreboot. libreboot was a means to simplify it. its "core" is still very alive.
Coreboot is exactly what Purism laptops have.
PureOS: Freedom, Privacy, and Security
31–40 of 51 posts
Re: PureOS: Freedom, Privacy, and Security
#32Earlier quoted context omitted.
I love qubes my only gripe is that they use the zen hypervisor instead of a minimal formally verified os such as sel4 which I think would go a long way in strengthening the isolation between “domains/containers/etc”.
What are your problems with Xen? They explain their choice very well: https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead... .
SEL4 would be a better choice because it is formally verified, there is a much smaller chance of vulnerabilities in SEL4 vs Xen because of this.
Re: PureOS: Freedom, Privacy, and Security
#33Personally I think QubeOS is probably the best option in terms of Privacy and Security at this stage. If your hardware can handle it (16GB RAM would be best). I would seriously consider QubeOS over PureOS if privacy and security are your concerns. It works pretty well and I've been using it for a while now on not so recent hardware without much issues. Their compartmentalization and seamless virtualization is just am…
Qubes is fantastic but as a PSA the hypervisor's kernel doesn't support newer GPUs such as AMD rx5000 (AFAIK rx580 is the newest supported one). Learned this the hard way. Qubes 4.1 will bring the support, once it's complete https://github.com/QubesOS/qubes-issues/milestone/20
Re: PureOS: Freedom, Privacy, and Security
#34Being unable to connect to the Internet or any network due to a lack of WiFi support is a strong privacy and security protection mechanism indeed. And the freedom is provided by removing your choice to use nonfree WiFi drivers. Leaving that decision to you with a warning of its implications (ala Debian) is not really freedom because you'll make the wrong choice. Don't get me wrong, I'm a big fan of FOSS, but not of d…
If there only was a list of chipsets with open source drivers https://en.wikipedia.org/wiki/Comparison_of_open-source_wire...
Re: PureOS: Freedom, Privacy, and Security
#35Earlier quoted context omitted.
What are your problems with Xen? They explain their choice very well: https://www.qubes-os.org/faq/#why-does-qubes-use-xen-instead... .
SEL4 would be a better choice because it is formally verified, there is a much smaller chance of vulnerabilities in SEL4 vs Xen because of this.
From the above link:
What about safe languages and formally verified microkernels?
In short: these are non-realistic solutions today. We discuss this in further depth in our Architecture Specification document: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a....
Re: PureOS: Freedom, Privacy, and Security
#36Personally I think QubeOS is probably the best option in terms of Privacy and Security at this stage. If your hardware can handle it (16GB RAM would be best). I would seriously consider QubeOS over PureOS if privacy and security are your concerns. It works pretty well and I've been using it for a while now on not so recent hardware without much issues. Their compartmentalization and seamless virtualization is just am…
Qubes is fantastic but as a PSA the hypervisor's kernel doesn't support newer GPUs such as AMD rx5000 (AFAIK rx580 is the newest supported one). Learned this the hard way. Qubes 4.1 will bring the support, once it's complete https://github.com/QubesOS/qubes-issues/milestone/20
Any notes on the VM integration in general? Been looking forward to a "Windows subsystem for Linux" style thing where I can run Visual studio and games without actually having to deal with Windows as a primary OS =P
Re: PureOS: Freedom, Privacy, and Security
#37Personally I think QubeOS is probably the best option in terms of Privacy and Security at this stage. If your hardware can handle it (16GB RAM would be best). I would seriously consider QubeOS over PureOS if privacy and security are your concerns. It works pretty well and I've been using it for a while now on not so recent hardware without much issues. Their compartmentalization and seamless virtualization is just am…
What is the response of QubeOS to the famous Theo de Radt critique[1] that virtualisation is basically adding another layer (hypervisor) of possible exploits just below the existing one (kernel)?
Re: PureOS: Freedom, Privacy, and Security
#38Earlier quoted context omitted.
SEL4 would be a better choice because it is formally verified, there is a much smaller chance of vulnerabilities in SEL4 vs Xen because of this.
From the above link: What about safe languages and formally verified microkernels? In short: these are non-realistic solutions today. We discuss this in further depth in our Architecture Specification document: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a... .
Interestingly enough they only mention it being unreasonable for x86, it would be interesting to see SEL4 supported for ARM (of which SEL4 already has a verified kernel for).
Re: PureOS: Freedom, Privacy, and Security
#39Earlier quoted context omitted.
From the above link: What about safe languages and formally verified microkernels? In short: these are non-realistic solutions today. We discuss this in further depth in our Architecture Specification document: https://www.qubes-os.org/attachment/wiki/QubesArchitecture/a... .
Interestingly enough they only mention it being unreasonable for x86, it would be interesting to see SEL4 supported for ARM (of which SEL4 already has a verified kernel for).
Re: PureOS: Freedom, Privacy, and Security
#40Personally I think QubeOS is probably the best option in terms of Privacy and Security at this stage. If your hardware can handle it (16GB RAM would be best). I would seriously consider QubeOS over PureOS if privacy and security are your concerns. It works pretty well and I've been using it for a while now on not so recent hardware without much issues. Their compartmentalization and seamless virtualization is just am…
What is the response of QubeOS to the famous Theo de Radt critique[1] that virtualisation is basically adding another layer (hypervisor) of possible exploits just below the existing one (kernel)? [1]: https://news.ycombinator.com/item?id=8393940
Just compare the number of lines of code between the Linux kernel and Xen. You will see how much lower probability of a bug becomes if you use the latter.