What is the "Pixel" of secureblue ?

xxxborisxxx

First,

I want to thank both the developers, donors and other community members of GrapheneOS for all their participation, work, and sacrifices.

I recently came across "secureblue" which is intended to be the GrapheneOS of the for desktop — secureblue.dev

I heard its members are part of the GrapheneOS community. Even the website style suggests that.

My question is, what would be the "Pixel Phone" for this?

I understand you could probably just choose any computer that can run Linux.
But I am simply looking for personal suggestions.

I like the build of the Razer laptops, (I am completely ignorant of its security guarantees).

So help me out, what computer would you recommend for "secureblue"?

raccoondad

xxxborisxxx most desktops have no security standards comparable to the pixel, maybe some macbook models may hit closer than standard Intel CPU based desktops

leafnose

xxxborisxxx
Short answer: It does not exist.

Longer and very incomprehensive answer:
Read the Important Notes from Qubes regarding the difference between Intel and AMD CPUs, which should also be the case for secureblue.
Maybe you’ll want the possibility to use an open-source boot firmware?
TPM, obviously.
You’ll also probably want to use ECC RAM.

Xtreix

xxxborisxxx secureblue aims to reduce the insecurity of Linux, secureblue is good, however, it does not aim to become the GrapheneOS for desktop, the fact that secureblue uses strict SELinux policies, hardened_malloc and Vanadium patches for Trivalent, among other things, does not make it a GrapheneOS for desktop, the security architecture of desktop model is broadly and significantly lacking.

v0rt3x

xxxborisxxx
need use intel 12gen with Intel CET
nice way use HP Chromebook Dragonfly i7-1265u
use depthcharge-tools
after install SecureBlue need tun Glibc for enable SHSTK & IBT:
add to /etc/systemd/system.conf.d/cet_glibc.conf:
[Manager] Environment=GLIBC_TUNABLES=glibc.cpu.x86_shstk=on:glibc.cpu.x86_ibt=on

and more more more ;D

DeletedUser405

Xtreix does not make it a GrapheneOS for desktop, the security architecture of desktop model is broadly and significantly lacking.

Yeah GrapheneOS for desktop is just GrapheneOS desktop mode

But Windows Secured-Core PCs are the most secure PCs you can get for secureblue, specifically either Dell or Lenovo

TrustExecutor Maybe look out for something outside of the x86 ecosystem? I'm not sure if secureblue runs on anything else thiugh.

ARM support is planned but not yet implemented

ryrona

I think you can more or less get any PC hardware. Pretty much all available hardware have way more security implemented than any desktop operating system is using. Secure Boot support and TPM2 support is standard, since Microsoft requires it for Windows 10/11 certification. This would be enough to implement full boot verification and a Weaver like disk encryption scheme with hardware throttling of unlock attempts. But there is not a single operating system out there that implements that.

I feel PC hardware is often criticized for being insecure compared to Pixels, but the truth is, the security features that already exists aren't used at all. Why would any PC hardware manufacturer be interested in implementing more security features, if the ones that are already broadly available isn't even being used by operating systems.

I feel we need to start by making operating systems actually use the security that is provided by the hardware. So I feel we need to start by making SecureBlue implement boot verification and Weaver. I posted a proof-of-concept of strong boot verification here a month ago or so, to show it is feasible. I know Fedora is doing changes to the foundation of their atomic distributions to enable boot verification, so SecureBlue might get partial support for it in a few years for free. And Weaver seems pretty straight-forward to implement. I plan to do a proof-of-concept of that too, maybe in a few months.

argante

I agree with the opinion that Linux distributions and the Linux kernel itself don't utilize the hardware security features offered by modern CPUs. This is all for greater portability. Even if they try to use the code, it's a very ugly implementation. Just look at the glibc implementation of memcpy() . First, the CPU ID is checked, and then the code jumps to the appropriate section. However, all implementations for each CPU are contained within the compiled memcpy object. This makes such code bloated and large, but it is portable. When it comes to hardware security support, it's difficult to talk about code portability, so there's simply no incentive to add such support in either the Linux kernel or libraries.

ryrona

argante First, the CPU ID is checked, and then the code jumps to the appropriate section. However, all implementations for each CPU are contained within the compiled memcpy object. This makes such code bloated and large, but it is portable.

Portable memcpy():

void *memcpy(void *dest, const void *src, size_t n) {
    size_t i;
    char *d = dest;
    char *s = src;

    for (i = 0; i < n; i++) {
        d[i] = s[i];
    }

    return dest;
}

argante When it comes to hardware security support, it's difficult to talk about code portability, so there's simply no incentive to add such support in either the Linux kernel or libraries.

Interesting observation, maybe that is some reason for the slow adaption. I still guess distributions such as QubesOS that already demand specific hardware features (virtualization with IOMMU mapping) might be interested though, and security focused distributions such as SecureBlue, which may also be more interested in security than maximum device compatibility.

TrustExecutor

Maybe look out for something outside of the x86 ecosystem? I'm not sure if secureblue runs on anything else thiugh.

argante

ryrona Oh no, this is painfully slow :) Try this:

void *memcpy(void* dest, const void* src, size_t n)
{
    char *d = (char *)dest;
    const char *s = (const char *)src;
    char *e = d + n;

    while (d < e) {
        *d++ = *s++;
    }

    return dest;
}

CPU: Linus doesn't seem to like hardware solutions. He even criticized the AVX512 and he's referring to portability:

It's a prime example of something Intel has done wrong, partly by just increasing the fragmentation of the market.

Solutions that increase security, for example for Intel CPUs, therefore have difficulty gaining support and acceptance.

ryrona

argante Oh no, this is painfully slow :) Try this:

I am pretty sure it will be easier for the compiler to auto-vectorize my solution to AVX512 though :)

(If I fix the missing const so it compiles at all)

argante Solutions that increase security, for example for Intel CPUs, therefore have difficulty gaining support and acceptance.

Though virtualization is supported just fine. It is just, the Linux kernel itself refuses to use it to improve its own security. TPM2 is also supported just fine, as is Secure Boot more recently. No further support would be needed from the Linux kernel to implement many security features, only from the rest of the Linux distribution eco-system.

argante

ryrona I am pretty sure it will be easier for the compiler to auto-vectorize my solution to AVX512 though :)

This is another risk. Long ago, a programmer could expect the compiler to generate what he expected. However, compilers began racing to optimize, and today you have no guarantee what will actually be generated. Unfortunately, compilers can often remove large chunks of code responsible for security. Even implementing explicit_bzero() without LTO breaking it was a significant challenge.

In my opinion, Linux will gradually be replaced by more modern, but much simpler solutions. See, for example, RedoxOS or Asterinas.