Producing a trustworthy x86-based Linux appliance
mjg59.dreamwidth.org
mjg59.dreamwidth.org
What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect?
When the proprietary software industry is already using technology, I don't think we benefit by refusing to touch it ourselves. We can use this tech to lock down devices that are better off locked down, and where we're not violating user freedom in the process. We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect. Refusing to do the good things isn't going to slow down the spread of the bad things.
I am not super mad if I have to run my custom kernel in a VM. It substantially reduces the surface area exposed.
We can use this to make it harder for activists to have their machines seized and compromised in a way they can't detect.
This argument is often-made and I hate it because it advocates destroying the freedom of many just for the needs of a tiny minority --- and if a nation-state is going after you, it's pretty much game over unless you can create your own hardware.
Refusing to do the good things isn't going to slow down the spread of the bad things.
Maybe to you it's a good thing, but to many of us, that is the equivalent of giving Big Tech the noose and saying "don't put it around my neck!" (The saddest part is how many will happily work in these noose-factories, either oblivious to or convinced that what they're doing is "good".)
Am I missing something? This seems to be incorrect, this is explicitly a case where you, the hardware owner, controls the signing keys. It's nothing like DRM, that is a case where an outside person controls the keys.
You mean... The last decade or so? Pretty much Mobile period sans the Librem 5 and I think maybe one other? Anything with an ARM chip that'll run windows must be secure booted and signed by Microsoft.
Or how about Nvidia(mostly)/AMD(to a lesser degree) video cards, where the entertainment industry increasingly relies on cryptographic attestation to constrain what people can do with hardware they bought? There is no "fully unlocked" buying option, and trying to divest yourself of Nvidia is impossible while being able to use your card to the fullest.
Or John Deere with their crippled hardware as a service model?
I'm all with charging for convenience. That's a value add. I'm not cool with intentional crippling, and extortionate practices whereby the manufacturer maintains ultimate control after first sale either legally or practically through privileged access to signing keys.
Just look at how fast the industry flipped over from dumb TVs to smart TVs, a similarly competitive and low margin market. I haven't been able to find a dumb TV at a big box store in years and the only options left are for commercial signage displays that command a large premium - largely made by the same brands that make the smart TVs.
I have a Pinephone myself but Android and iOS have already sucked all the oxygen out of the room - it's still nowhere near ready to be a daily driver and it's a decade plus late to the party. I got a small open source 3G cell tower for development years before the Pinephone even hit the drawing board.
Absolutely no web presence outside of (essentially) a brochure and email complaint form. I thought about complaining but I really don't care enough.
I think all the devices that provide more security by being heavily locked down should basically have a tinker switch. If you really want to write your own firmware for your phone or your dishwasher, flip it to tinker mode which locks you (maybe permanently) out of the software it shipped it and let you flash whatever on to it. The manufacturer gets to waive all responsibility for your safety (digital, physical, etc.) from that point onward.
Bonus points if it just blows away the keys to the onboard software so you can use the security mechanisms for your own code.
(And by the way - remotely exploitable dishwashers? What the heck is the world coming to?)
All I imagine is someone running their own firmware on an appliance, doing some unseen damage, and then reverting to the onboard firmware and getting hurt. It would be a field day for lawyers.
I completely agree that this sucks and it's the same reason robotics has proceeded at a snail's pace. God forbid making a Roomba with a more powerful vacuum, what if it ran over someone's toe.
Without free software implementations of secure boot et al. all this would just happen behind closed doors. At least with this the field progresses and you'll have the tools to secure your own applications when the right project comes.
> What good is having all the source code in the world if I can never put my (or anyone else's) modifications to it into effect?
Well, it'll be more difficult to get pwned, for one.
For example voting machines should be done in this way. Open source software such that outsiders are able to verify + a secure boot process such that anyone can verify that the machine is really running the code it is supposed to run.
Of course we should all still be very careful of what we accept in terms of control of our hardware. And I agree with you that things are not moving in the right direction there, with locked ecosystems everywhere.
I think most people would prefer no voting machine software at all, seeing how most people can not "verify that the machine is really running the code it is supposed to run" but can indeed verify a paper ballot.
And of course signing a huge code bundle is the farthest possible thing from "run exactly the software you think it runs". Console manufacturers keep learning that. You really wanted to run that WebKit version that turned out to instead be a generic code execution widget? Think again.
The reason I bring it up is that one of the benefits of open source that is often mentioned is the ability to verify that it does what you think it's doing. Doesn't matter whether it's a voting machine, a self driving system or an ATM or whatever. It's still good for open source to have the capability to do this kind of proving in cases where you want it.
The majority of people, with normal sight and no mobility impairment, may be fine with paper ballots. But for some of us, an accessible voting machine is more than a convenience, as it enables us to independently (and therefore privately) cast our votes.
Even a mobile app to guide blind users on the ballet would be more secure.
Basically excludes any black box machines, block chain, cryptography and any existing computers.
I tried to simply disable "secure boot" in the BIOS settings and then the boot loader just did absolutely nothing. Hot fucking garbage.
Apparently, if you have "secure boot" available during the install it will use "secure boot" without any way to opt-out.
You might also try signing the kernel module yourself (the manual method at the bottom of that page)?
What more to want from a security perspective? In-device protection from flashing? Sounds similar to security through obscurity. I'd prefer easy ways to check what a device is flashed with. Something like a checksum calculator device. Not sure if that's a reasonable idea.
Out of band firmware validation is a real thing (Google's Titan sits in between the firmware and the CPU and records what goes over the bus, and can attest to that later), but that's basically just moving who owns the root of trust, and if you don't trust your CPU vendor to properly record what firmware it executes you should ask whether you trust your CPU vendor to execute the instructions you give it. Pretty much every option we currently have is just in a slightly different part of the trade off space.
I looked into TPM stuff a few years ago, and it all seemed pretty useless to me.
First of all, the entire key-protection house of cards relies on the assumption if you've booted the right OS, the keys can safely be unsealed. But the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues.
Second of all, if you're worried about someone snatching your laptop or phone, full disk encryption where you type the password at boot gets you 99% of the protection with much less complexity. And the much lower complexity means many fewer places for security bugs to be accidentally introduced.
Third, if you're worried about evil maid attacks where someone dismantles your laptop and messes with its internals without you knowing then gives it back to you, then the TPM isn't sufficient protection anyway. They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway.
And fourth, the TPM doesn't have a dedicated hardware button (making it a shitty replacement for a U2F key) and doesn't have an independent clock (making it a shitty replacement for TOTP on your phone) so it's not even a good replacement for other security hardware.
About the only use I can see for this stuff is if you're some huge multinational company, and you think even the authorised users of your computers can't be trusted.
>the TPM does nothing to protect from security issues beyond that point, which is the vast majority of security issues.
I hear this type of thing often but it's the wrong mindset to take when dealing with this stuff. Security holes in one part of the stack are not an excuse to avoid fixing security holes in other parts -- if you do that, you now have multiple security bugs that are going unfixed.
>And the much lower complexity means many fewer places for security bugs to be accidentally introduced.
This doesn't seem to make any sense, avoiding securing the boot process does not mean the boot process is any less complicated or somehow has less parts that can be compromised. TFA is just describing how to secure the parts that are already there.
>They can simply put in a hardware keylogger, or get direct memory access, in which case it's game over anyway.
I'm not sure how this is related, building a tamper-proof case seems to be outside of the scope of this. This seems to cover only the software parts.
Of course it does: Not only does secure boot add an extra point of failure, it's a point of failure that's specifically designed to be highly sensitive, and to fail locked, and that hardly anyone in the kernel development community is testing with.
> I'm not sure how this is related
From a computer owner's point of view, the TPM's secure boot functionality exists only to protect against attackers with physical access to the device. After all, if a malicious attacker making a remote attack has the ability to replace your bootloader or reflash your BIOS, they've already got everything.
In other words, secure boot is there to protect against an evil maid [1] removing your hard drive, replacing your bootloader with one that logs your full disk encryption password, then subsequently stealing your laptop and password at the same time. Or something of that ilk.
However, the TPM is insufficient to protect against such attacks.
As such, secure boot fails to provide the one thing it claims to provide.
A serious system - like the xbox's security system - (a) has the functionality on the CPU die, and (b) has the hardware for full speed RAM, bus and disk crypto, all with keys that are inaccessible to the OS.
>However, the TPM is insufficient to protect against such attacks. As such, secure boot fails to provide the one thing it claims to provide.
I don't think anyone is saying TPM or secure boot alone is going to prevent against such attacks. It needs to be combined with some other physical protection measures, e.g. a tamper-proof case of some kind.
I had issues wrapping my head around this as well with regards to things like Network Boot etc, where I could not for the life of me understand or justify a boot process having a runtime capable of doing all this extra cryptographic/network nonsense when all I bloody wanted was my OS, up, now.
Not to get nostalgic, but that magical era for a user around Windows XP with a <5 second boot was just that; magic.
I know all the oldtimers will come out of the woodwork with horror stories of competing, sloppily specified BIOS implementations, the pain of malware hiding in CMOS, the threat of rootkits, etc... And the admins will chime in with "How do you expect me to power on the thousands of servers in my datacenter without network access during boot"?
Those are valid and real situations in isolation I can stomach. I cannot, however, stomach a boot process whereby a non-owner arranges things in a way where it is guaranteed that they get the final word in deciding how hardware you paid for is used, which requires the composition of those services.
xboxes and iphones don't need tamper-proof cases.
Software is already here, particularly in social media (mastodon/SSB vs Facebook). That hardware eventually gets there seems to me an inevitability (arguably we're already at least partially there, as evidenced by the fact Purism/Pine64/etc exist).
I still don't see it as a problem, though, because an individual can have different technical interfaces (devices, OSes, etc) for different purposes.
Generally, I put my personal stuff on systems I understand/control.
For some things, like watching TV, I'm okay with going to Netflix because that transaction is expected to be transitory. If Netflix disappears or declares themselves a new world order tomorrow, I can simply unsub and no harm done.
Where things get problematic is when so much of someone's life is wrapped up in a mono-corporate cocoon (e.g. Amazon shipping things to your house and running your servers, or Google serving you search results + mail + maps).
But your TV manufacturer still wants to provide Netflix to other users and Netflix decided to require all their devices to run its trusted code if they want to provide Netflix to anyone, whether you in particular want it or not. So your choice is to trash your existing TV and track down a manufacturer that doesn't have any support for Netflix, Hulu, Youtube, Amazon Prime, etc. at all to buy a new TV that doesn't ignore your choice. With TVs you might be lucky since there is a large market for dump displays that avoid any TV related functionality anyway, of course there might be restrictions in the license between Netflix and the TV manufacturer to close that loophole too, maybe limiting sales of dumb displays to specific types of users.
So much for your $1000 TV that had Netflix and only Netflix builtin, and will refuse to boot when the cryptographic check fails becaused you changed the string that points to http://www.netflix.com to http://www.notnetflix.com
edit: the only people who think that being locked-down is a feature are rationalizing technologists who indirectly profit from that arrangement. It's not even more secure. The methods used to control locked-down devices (namely constant network connections and cloud storage/control) are the most vulnerable attack surfaces we have, and the source of virtually all contemporary security disasters.
It just means that you can be sure no one else has tampered with your device.
To me it seems very silly to not follow this line of thought just because someone in the future might use it lock out hackers. This is like leaving bugs unfixed because someone might have a use for it.
Ironically TiVo is long gone from living rooms.
The iPhone is locked down, consumers buy 5.5 Android phones for every 1 iPhone. But rich users buy iPhones, and they also buy software, so...
But you don't own (for example) Netflix. So Netflix can exclude you if you use your computer in certain ways, right?
i.e. if you refuse to use a secure boot infrastructure and do remote attestation of the trust chain to Netflix, they can refuse to provide you service - obviously based on the assumption that this was all made clear to when you signed up.
I try not to whip that out because it's all fun and cool til they do somethimg you don"t like.
Both are presumed to have extended physical access to the device, any requisite knowledge, tools, etc.
The normal solution to this is to have a password that only the owner knows. I'm assuming that that hasn't been used in this case because the intention here is actually to lock the owner out and only allow the manufacturer access to change the device. Is that the case?
Please don't get me wrong - I would love a solution to this problem that wasn't isomorphic to a solution that can be used to lock out users. But I've spent the last 8 years or so of my life trying to do so and haven't succeeded yet, because the hardware we have available to us simply doesn't seem to give us that option.
I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead?
> ... the hardware we have available to us simply doesn't seem to give us that option.
Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?
If the system is compromised then it can just report the expected password hash. You can't trust a compromised machine to tell the truth.
> I mean, surely the same problem exists for any data stored on the device (keys, hashes, whatever)? If there's a way of storing a key chain securely on the device so it can't be modified by an attacker, can't a password be stored there instead?
Various bits of TPM functionality can be tied to requiring a password, but it's hard to actually turn that into something that's more freedom preserving while still preserving the verifiability. What you want is the ability to re-seal a secret to new values only as long as you have the password available, and I don't /think/ you can construct a system that does that with the features the spec gives you.
> Is that because the manufacturers don't give the option, or because technically there isn't a way of giving the option?
Unclear. There's little commercial incentive for people to come up with elegant solutions to this, and I can't immediately think of a model that would be significantly better than the status quo.
I think the GP's point is that you assume the system can't tell the truth so you do the validation server side rather than client side. Sure, the system could send a different password hash, but as long as you don't publish the correct hashes it's not going to matter if the client sends alternative hashes since that validation happens server side and thus the client wouldn't know what hashes are valid.
...and deploying the keys involves setting UEFI in the Setup mode, which is protected by the firmware setup password.
Granted, I didn't verify where the keys are stored and in which format once deployed. But it would be pretty disappointing if they were just copied to another place without any encryption or signing authorized by the password.
The user must not be asked to enter that password repeatedly to do everyday tasks, otherwise it is easy to trick them into entering the password into a malicious input field.
More important, the user must not be expected to routinely waive all protection for required tasks. For example, the user is often expected when installing software on a computer to give administrator privileges to an installer script which comes from an untrusted source. The user is expected to "make sure the source is trusted". This does nothing but put the blame on the user, who cannot do that in a meaningful way at all, yet is expected by other factors to install and use the software.
The user must not be forced by other factors to enter the password and take measures which are not just unsafe but are actually known to attack the system, exfiltrate data or similar.
But we haven't come up with any better methods of doing this. Some tasks require making changes to the machine that could be evil, so we have to ask the user for permission to make those changes (to stop evil people making those changes with no permission). The more parts of the device we protect, the more we have to ask for permission, and the more routine the granting of that permission is and the less effective the whole permission-granting mechanism is.
Coming up with a decent, workable, solution to this would be great. As you say, in an ideal world the onus would not be on the user to verify that the software they're installing is not malicious (with no way of effectively doing that).
hmm, sounds like a problem that could be lucrative to solve...
No the intention is to lock out functionality. Either programming code that can't be decrypted without secure boot actually booting security, or access to remote networks. That second one is where the controversy comes in because it means if the owner of the device is Netflix (or FB/Youtube/HBO/...) and the network is owned by Netflix you cannot change anything on the device in your house and still watch Netflix.
Because of this locking out functionality it is referred to as "rendering your device useless". It can of course still do everything it can do, at the owner's request, just not with Netflix' data.
If that happens, it will create a market opportunity for websites without DRM or such checks. If you fuck with the ergonomics, you necessarily always create a market opportunity for competitors IMO. That being said, I also would rather use open computing platforms where I can easily install whatever OS, drivers, hardware or userland software I please.
There's the theory of how incentives should work in free markets, and then there's the practice of exactly how savvy consumers can really be, and whether non-consumer interests can organize themselves in a way that easily overpowers the consumers.
I've thought about this recently regarding hardware DRM in Android phones. Google has Widevine which has different levels of support, and Netflix, for example, will only send high definition streams if your device supports L1 Widevine which means it will only be decrypted in "secure" sections of hardware and the user cannot access these areas. This is intended to stop user access to the unencrypted media.
This hardware is widely available in Android devices already, so why would Netflix* do otherwise? And if you want to stream HD from Netflix then you'll get a device that supports it because Netflix require it. However, how did our devices end up with this technology to begin with? If consumers acted in their own best interest, why would they pay to have this extra technology in their devices that protects somebody else's interest? If this technology wasn't on our devices already, do we think that Netflix wouldn't be offering HD streams anyway? Basically, if consumers could organize as effectively as corporate interest, would this technology have made it to our devices at all?
It's possible that it would have. Perhaps overall people would deem it worthwhile to acknowledge and protect corporate rights holders so that they can continue to produce the media they want to consume and stop people consuming it for free. Personally, I would not have accepted this bargain and I would have left it up to the media companies to manage their own risks and rewards, and I strongly suspect that they would have found profitable ways of doing so that would include non-DRM HD streaming. I think it's tough to say what an educated consumer would think on average because so few consumers think about these things and those that do may have a strong bias that led them to research it in the first place.
* I'm saying Netflix here because it's easier, but in reality I'm sure a lot of the content they licence will require DRM so it's not entirely up to them
Trusted computing is great if you're an IT admin (or even an "IT admin of one") and you order devices with an open/unsealed boot-key store from your hardware vendor. You can install your own boot keys on your fleet of devices, seal the boot key store, modify OS images/updates to your heart's content, and then sign those modified images with those same keys. Now only the images you've created will run on those computers. People won't even be able to install the original, unmodified OS on those machines; they'll now only ever run the version you've signed.
This isn't just about employees not being able to futz with the MDM. Even the OS vendor won't be able to push updates to your managed devices without your consent. You'll truly have taken control over what code the devices will (or more importantly, won't) run.
In any situation where the person intended to have physical access to the device is not the same as the owner-operator of the device, this kind of thing is essential. Obviously, public-use computers in libraries et al. But also, ATMs. Kiosks. Digital workplace control panels and dashboards. On all of those, nobody's around to monitor the hardware to ensure that someone doesn't just open the back and swap the hard drive out for their own. With TCB, swapping the hard drive out just makes the device not boot.
Because the two go hand in hand in the wild already. Just look at all android phones. Where you have to make a pact with the devil to get your unlock keys (if possible at all) and that still doesnt give you full override capabilities and also marks your device as "tainted" so you can say goodbye to banking apps and increasingly more stuff.
I'm not concerned about enterprise deployments because companies had a lot of tools to (rightfully) lock down devices given to their employees since the dawn of computing.
However I am concerned about the philosophy coming over from phones to the desktop space with announcements like https://news.ycombinator.com/item?id=25191319
Consumer electronics — phones, game consoles, etc. — these are places where people choose to buy the dang thing in the first place, despite the restrictions the manufacturer imposes. Trusted computing isn’t the problem, it’s a tool used by an abuser against their Stockholm-syndrome victims. The abuser themselves — and society having no social norms that protect against developing this particular Stockholm-syndrome — are the problems.
The stuff people want from these devices — the reason they buy into these locked-down ecosystems — is almost always just the platform-locked software that runs on them, not the distinctive hardware (that the software doesn’t usually even take advantage of!) But that fact is great for the end-user: it means that, as long as one person figures out how to defeat the platform’s software DRM, and another person figures out how to write an emulator for the hardware, then there’ll never a reason to lock yourself into these ecosystems. When software is the USP, users can just use an alternative conformant implementation of the same platform (from the software’s perspective) that isn’t locked down, to run said software.
The same way that locking your front door or being home or parking in a guarded parking lot will be efficient in deterring opportunist thieves and even most regular thieves.
Absolute security doesn't exist but that doesn't mean security measures are futile in general.
Now I'm going to propose a more likely future scenario. Imagine you are on another planet and there is a software flaw that needs to be patched. Do you want to have to beg some billionaire millions of miles away for the privilege of modifying the code, or do you want the ability to fix it as soon as possible? If its a time-sensitive issue consider the consequences of having to fumble around with deploying signed patches, or installing a new key and updating everything to work with the new key.
None of these trust devices are perfect, they might leak data that can be used to infer keys through side channel, or can be physically inspected, etc, I think we can all agree they are not perfect. So if the security model breaks down with physical access then the only adequate solution is physical security. Putting your faith into some crypto function that will be obsoleted by time is not a winning defense. It's also possible the keys may have been obtained by a malicious adversary, rendering this mathematical security layer ineffective at best. If I can install new keys, then an attacker can also install new keys. If the imperfect security measure causes more problems than it solves, then its worth rethinking.
What problem would it ACTUALLY solve in this scenario? Maybe it could be used to mitigate a breakaway civilization by only allowing patches through remote update channels, keeping new outposts fully dependent on Earth. Potentially at the cost of real lives if that update channel is broken somehow. Though someone always figures out a way to break the lock :)
Please I don't want to hear about some hypothetical dissident of a tyrannical regime, they should have destroyed the device before capture if they had any wits. The regime would probably be forcing its citizens to run fully validated stack anyway and would be all up in their business for (red flag) installing their own key instead of government approved key... Corporate security? Lol do you think your petty secrets are worth restricting humanity by normalizing imperfect security measures? Some of these corporations need to be kept in check somehow, they have too much power already.
The only future I'm on board with is one with a robust well tested software ecosystem controlled by its users/operators/owners, not a careless conglomeration that prioritizes the well being of it's shareholders, or crushing its competition.
One such reason is simply compliance: if a device is only capable of safe operation when running within a certain spec and dangerous otherwise, regulatory frameworks might require manufacturers to ensure said specs are honoured.
While a manufacturer can and must provide the "robust and well tested software ecosystem" you yourself desire, Mrs random tinkerer might not. A device running with modified firmware might therefore lose its operating license and - best case scenario - get damaged in the process, or on account of it being dangerous if operated outside of spec endanger the life, health and/or property of its owner/user/operator.
There's no need to dream up hypothetical scenarios on distant planets when all it takes is a typo to turn an MRI machine into a waffle iron for people or an Insuline dispenser into a super effective suicide device.
Not every device is intended- or safe to be tampered with by unqualified laypeople.
It's also pretty arrogant to assume just because you know how to program to also have sufficient knowledge to be able to understand and make meaningful changes to every conceivable device in existence that uses some kind of firmware.
There's a reason certain jobs require qualification and there's also good reasons certain devices are not to be messed with by unauthorised/unqualified people either.
Maybe I've just had too many horrific experiences with software updates and that is causing some bias. Or seen too many science fiction films.
"Those who give up freedom for security deserve neither."
Disk encryption then became practical, and defeating it requires a running, vulnerable machine (for cold boot) or tampering+user interaction (for evil maid).
Secure Boot makes those even harder - you will have to compromise the TPM itself.
All of this is to say it is still possible to attack a machine with physical access, but you now have to enage in further security breaks. It's not really "game over" anymore as there are further defensive to defeat.
Caveat: I seem to recall dm-integrity being somewhat flawed and vulnerable to rollback.
https://blogs.oracle.com/bonwick/zfs-end-to-end-data-integri...
Definitely worth reading the Wiki: https://osresearch.net/
Can be run on a variety of laptops, including a ThinkPad X230. Ships by default on Librem laptops. Uses the second-to-last approach described by the article (TOTP-based).
Why can we not use something like Guix by declaratively setting up a system [0] and for extra safety have it run in a container [1]?
[0] https://framagit.org/tyreunom/guix/-/blob/99f47b53f755f0a6cb...
[1] https://guix.gnu.org/en/blog/2017/running-system-services-in...
The ME has had many security vulnerabilities and probably more to come. For an appliance some old CPU might be good enough, but it does not get security updates. Some claim the ME might contain a NSA backdoor. That the ME can do networking certainly doesn't give confidence. The US government can order CPUs without ME, but nobody else can. Does not raise confidence either.
Trustzone is a secure execution environment, mostly isolated from normal CPU operation. Wasn't it so that it cannot even access main memory???
ME is really more privileged than the CPU?
I have not heard about Trustzone doing networking. But ME can supposedly do even WLAN while the CPU is not running.
Disclaimer: I am not a hands-on expert at that level, more like an armchair pilot...
On top of that, it is well known that governments research or buy 0-day hardware and software vulnerabilities and keep them secret to be used as weapons.
ME is just a fraction of the attack surface. When I read the title of the article I thought "trustworthy" was about mitigating hardware vulnerabilities.
At this stage it's practically impossible. :(
So you need to trust Microsoft for the first keys :)
[1] Every machine I've ever had access to has. If anyone has an x86 machine with a Windows 8 or later sticker that implements secure boot but doesn't let you modify the secure boot key database, I have a standing offer that I'll buy one myself and do what I can to rectify this. I just need a model number and some willingness on your part to chip in if it turns out you were wrong.
https://github.com/Foxboron/sbctl
It should hopefully end up being an improvement on efitools and sbsigntools. Tried posting about this on HN but somehow it's a topic with little to no interest, strange world!
However, they all do have the option to disable Secure Boot entirely (and you get a permanent red boot screen for the privilege).
You can make it difficult but defeating an attacker who can touch the hardware is for all intents and purposes impossible.
edit I found that Microsoft did the smart thing like Sony did with the original PS3 and allowed people to run their own code (but not XBox games) on their consoles, removing a large incentive for people hacking the console.
That doesn’t automatically make the security watertight though.
If you consider NSA or similar agencies a problem then you are in a world of pain anyway and using an entry level guiding blog post is certainly not appropriate.
For everyone else, this puts already quite a big defense layer to your arsenal even if not unhackable in absolute terms.
>The post is still somewhat valuable, but should really not use "trustworthy."
The posted article is dealing in absolutes, not me.
But if you really want it, writing a custom boot ROM and OS is probably the only way you can have an actually secure system (you might need a custom CPU as well).
Given the lack of skill and discipline of most programmers the whole TPM/secure-boot/UEFI/grub/Linux/dm-verity stack is likely full of holes, so just the assuming that it works as you'd expect will probably be disappointing.
For desktop computing ("personal computing", if you like), anyone here will agree.
But the article is specifically talking about securing appliances, and generally when talking about appliances, you're talking about rackable machines sold to the enterprise. There, they don't care a jot about being able to muck around with the machine - the whole point of an appliance is that you plug it in and go; that is more or less manages itself.
And for many of these customers, and of course any operating in a high-security environment (e.g. defence), this level of security is a feature, not a hindrance.
I have enough RAM. More than enough.
About 10+ years ago I was easily running the entire OS in 500MB of RAM on an underpowered computer, boot from USB stick, tmpfs (or mfs), no swap. Today, the amounts of RAM are even greater on a comparabley-priced equivalant, at least double, more likely triple or quadruple. I was not doing this to avoid some "anti-tampering" scheme, I just wanted speed and cleanliness, and not having to worry about HDD failures.
However I was using NetBSD not Linux. One thing I have learned about Linux, it is not nearly as nice in the way it handles memory exhaustion, or, in the case of this RAM disk setup, what we might call "running out of disk space". IME, NetBSD anticpitates and handles this situation better by default. I could routinely run out of space, delete the overgrown file at issue and continue working. I noticed an interesting comment recently from a Linux developer on resource usage under NetBSD: "Lastly, redbean does the best job possible reporting on resource usage when the logger is in debug mode noting that NetBSD is the best at this."
I like this RAM disk setup because it forces me to decide what data I truly want to save long-term. Any data I want to preserve I move to removable storage. The system is clean on every reboot. In a sense, code is separated from data. The OS and user data are not stored together.
Anyway, putting the entire OS in intramfs makes sense to me. Intramfs, or at least tmpfs, is a filesystem so the "you're going to want a filesystem" comment seems strange. Also I think the reason(s) one might want a more optimised, lower overhead HDD-based filesystem could be something other than "not enough RAM".