Realistically, no.

Theoretically, if you enable Secure Boot and a boot password through UEFI, it might be OK for some purposes, as an attacker clearing your Secure Boot settings would also reset the boot password, which you’d probably notice.

If you’re concerned about Evil Maid attacks, use Secure Boot with a TPM. If your only concern is getting the device stolen with you losing access, Secure Boot from my point of view is only a convenience feature for stuff like easier unlocking

EDIT: it should be mentioned that technically, Secure Boot doesn’t require the TPM and just checks the signatures. However, you’d need to check on each boot whether it’s actually enabled with the correct settings and that your device has not been reset. The automation of this is sometimes called Measured Boot, which the TPM is used for. Secure Boot by itself doesn’t protect you against sophisticated physical attackers. But the boot measurement gets thrown into the term because it makes sense.

At least that’s my understanding.

Clearing CMOS clears it, but you will lose the TPM attestation, which indicates tampering

I was about to write something similar. You’re just pushing the problem down the stack, and argon2 doesn’t fix that particular one anyways.

The facts are:

1. You always need an unencrypted entry point, so encryption can’t be your secure anchor (though it could never be anyways, you’re looking for authenticity there, not confidentiality)
2. As the original post states, making sure an attacker never has physical access to your boot or EFI partition works against that particular evil maid attack. It won’t protect from other threats however and isn’t very practical.
3. You need to authenticate your whole boot chain for actual protection, including initrd, which the linked article also rightfully points out
4. The only system available to normal users to provide authenticity protection mechanisms is Secure Boot (with implementations not always perfect)
5. In practice, you need to enroll your own keys to sign your initrd and have a mechanism to actually check it, or use something like a signed UKI
6. In your actual system, make sure your boot partition is only available to root - EFI mandates vFAT which doesn’t support owner attributes, so put on a restrictive mask (0077)
7. Your UEFI needs to be protected by password so that an attacker can’t just disable Secure Boot and replace your protected files

With all these in place, you should set up booting from an encrypted partition where they key is loaded from the TPM with sufficient PCRs bound and a PIN or something similar. I’m unaware of current solutions to easily have a kernel check against the registers during boot, so in case your system won’t decrypt with the PIN as your input alone, you know that your boot process has been altered (not necessarily malicious, could be a firmware update, but still).

Real security is hard, there is no easy solution if the vendor doesn’t control the hardware (which both Apple and Microsoft do), most users don’t care that much that distribution would push for it. You rather still have the unhealthy “open source is secure and TPM / secure boot is a Microsoft tool to lock out other operating systems” attitude.

PS. this is not meant as a guide for setting up a secure system, just some considerations when considering the approach.

TPM can be the fix, but it needs to be integrated into the boot process correctly.

https://0pointer.net/blog/brave-new-trusted-boot-world.html mentions some or most of the pitfalls

Were you banned or shadow banned?

I was only shadow banned once, however never banned normally.

Better than me getting shadow banned from reddit for using one, I appealed back then

Who hates ChromeOS? Never heard someone say that

While I do get your sentiment, we currently see in Ukraine what happens if you don’t have a defense industry: You’re reliant on other countries to supply you in case a hostile nation notices that you’re lacking it.

All that follows is my personal opinion, but for ease of writing, I’m gonna present it as facts.

Once you have grasped the advantage that Nix offers, all the fundamentally different solutions just seem s o inferior. When I first tried NixOS on a decommissioned notebook, the concept immediately made sense. Granted, I didn’t understand the language features very well – I mostly used it for static configuration with most stuff just written verbatim in configuration.nix, though I did use flakes very early on because of Lanzaboote. But just the fact that you had a central configuration in a single language that was able to cross-reference itself across different parts of the system absolutely blew me out of the water. I was a very happy and content Arch user, even proficient enough to run my own online repository that built from a clean chroot for AUR packages (if you use Arch with AUR packages on multiple systems, check out the awesome aurutils!), but after seeing the power of NixOS in action, I switched over all my machines as soon as I could - desktop, virtual servers (thanks nixos-anywhere!), main notebook and NAS.

People often praise the BSDs for their integrated approach – NixOS manages to bring that approach to Linux. Apart from GUIX System that I never tried because Secure Boot was a requirement when I last looked at other distributions, none of them have tackled the problem that NixOS solves, and it’s not even certain if they actually understand it. Conceptually, it plays on a whole different level. No more unrecoverable systems, even with broken kernels – just boot the previous configuration. Want to try changes without any commitment? nixos-rebuild test got you. Need an app quick? nix shell nixpkgs#app it is.

Plus the ecosystem is just fantastic. The aforementioned nixos-anywhere really helps with remote provisioning, using disko to declaratively setup filesystems and mounts, you have devenv which is a really good solution for development environments, both regarding reproducibility and features, and many more that I can’t mention here. There is nothing comparable, and the possibilities are unlike in any other ecosystem.

It’s not perfect for sure though, and documentation is sparse. The language concepts which allow one to “unlock” the most powerful features are different from what most people know.

I was lucky enough to have some downtime at work to get into the system a bit deeper (this was still for work though, just not my core skillset) by implementing a “framework” for our needs which forced me to not just copy and paste stuff, though I definitely did get inspired from other solutions, but to actually better understand the module system (I think?), thinking in attribute sets, writing your own actual modules, function library and so on. But in the end, it was definitely worth it, and I’m unaware of any other system that would allow what Nix and NixOS allowed me to build.

NixOS […] some packages are kinda old

Fair

that server will be going back to debian next summer.

I don’t think that will solve the “some packages are kinda old” issue.

Thanks for posting peertube content, it’s time people stop using YouTube

XMPP is a protocol, the GPL covers software implementing these protocols. They could use their own proprietary XMPP client and server without any legal issues.

Grey market chips usually include chips that failed quality assurance to prop up numbers.

50%?

HOLY FUCKING SHIT

These are absolutely disastrous numbers. This is worse than I would expect from illegally sources parts.

Even then, it might be minified or even obfuscated

The engine probably is free, but the code it runs often is not.

The NixOS ecosystem while maybe sometimes both chaotic and heavily centralized just seems miles ahead of what Guix System has to offer unfortunately; nix is a weird language (I’m not qualified to rate it but people have called it a bad DSL), but it does the job, and there were some factors that ruled out Guix System for me. Secure Boot support was one of them, which NixOS doesn’t support “natively”, but there is Lanzaboote. For better or for worse this kind of forced me to look into flakes very early.

Using it on all my machines (desktop and notebooks), can’t really complain – but then again, couldn’t really complain about Arch either

May I ask what the issue actually was? Was it about “working system” or about “working development system”?

I don’t recall needing more than two days for getting a system up and running for the first time, and in fact it worked so well that I switched all my machines to it by now; granted, I have changed a lot about the configuration ever since and there seem to be a lot of paths to take in the beginning and it’s not always clear which one to take. But getting a working system, even one suited for development (personally, I’d recommend a nix development shell for that), shouldn’t really take that long.

Well, that’s kind of a bromide. By extension, everything is a security risk. Managing and minimizing risks is the hard part.