Secure Boot and the 2018 MacBook Pro(michaellynn.github.io)
michaellynn.github.io
Secure Boot and the 2018 MacBook Pro
http://michaellynn.github.io/2018/07/27/booting-secure/
85 comments
As long as secure boot is optional, I think having the ability to use it is a good thing.
As an individual, the freedom to install whatever OS you want is important.
As a company, you want to have the option to bootstrap the software from a cryptographically signed image so that group policies, etc. can all be enforced in one long, auditable chain starting from the onboard TPM. While most employees might not need that, something like that is useful for making sure remote datacenter access is secure.
As an individual, the freedom to install whatever OS you want is important.
As a company, you want to have the option to bootstrap the software from a cryptographically signed image so that group policies, etc. can all be enforced in one long, auditable chain starting from the onboard TPM. While most employees might not need that, something like that is useful for making sure remote datacenter access is secure.
I worked for a big company with an IT department that was forcing strict policies on everybody. E.g. installing Skype could get you fired. But the developers working on projects for that company basically ignored the rules, because it was the only way to get anything done.
Not saying that there aren't companies for which this is desirable. Such companies exist. What I am saying is that their reasoning is bullshit and has more to do with some people keeping their jobs, so it's job security instead of actual security.
Not saying that there aren't companies for which this is desirable. Such companies exist. What I am saying is that their reasoning is bullshit and has more to do with some people keeping their jobs, so it's job security instead of actual security.
I think we're talking about slightly different things.
I'm a proponent of proportional amounts of paranoia. Restricting everyone is disproportional. Preventing developers from installing software on their dev boxes probably does more harm than good.
On the other hand, putting tight controls on computers people use for admin access to servers is not a bad idea if your company is big enough that only the dev ops guys really need to be in there with real regularity, or if your company handles sensitive data. Then the practical layer of security might be worthwhile to make getting into the datacenter via a compromised engineer or dev box harder.
That's the scenario I'm familiar with: secure boot on a separate machine, and a tight lid on what software you can put on the system, in order to guarantee a baseline level of hygiene for any system that talks directly with the datacenter.
I'm a proponent of proportional amounts of paranoia. Restricting everyone is disproportional. Preventing developers from installing software on their dev boxes probably does more harm than good.
On the other hand, putting tight controls on computers people use for admin access to servers is not a bad idea if your company is big enough that only the dev ops guys really need to be in there with real regularity, or if your company handles sensitive data. Then the practical layer of security might be worthwhile to make getting into the datacenter via a compromised engineer or dev box harder.
That's the scenario I'm familiar with: secure boot on a separate machine, and a tight lid on what software you can put on the system, in order to guarantee a baseline level of hygiene for any system that talks directly with the datacenter.
I don't know if this crosses the line into scary for me simply due to the fact that it can be turned off. Based on what I just read nothing would stop me from switching to the "No Security" mode and installing whatever I want.
We can look at phones and tablets, where bootloaders are locked down, to see that there is an interest in making sure that the secure bit doesn't get flipped by the user in the name of "security".
There's an incentive to disallow unauthorized software from running on your hardware platform: it forces users to go through approved channels for their software and data. If you own an App Store and services like iTunes, the financial incentives exist to ensure your users don't sideload content or use competing app/media markets.
There's an incentive to disallow unauthorized software from running on your hardware platform: it forces users to go through approved channels for their software and data. If you own an App Store and services like iTunes, the financial incentives exist to ensure your users don't sideload content or use competing app/media markets.
Based on what I just read nothing would stop me from switching to the "No Security" mode and installing whatever I want.
...for now. The frog boils very slowly.
...for now. The frog boils very slowly.
Everything is possible, of course, but Apple makes money from selling hardware, not from selling an OS; They're likely to keep letting you run what you want (which is in their interest so you don't buy hardware from another vendor even if you want to run Windows or Linux) -- although they might condition warranty and service on your computer running a blessed, signed and secure OS/X.
> Apple makes money from selling hardware, not from selling an OS
This reasoning is overused and wrong.
Apple's hardware is no good for other operating systems, it doesn't run well with either Linux or Windows, the support being shitty due to Apple's proprietary stuff. As an example the experience with the touchpad becomes much poorer and the battery life is reduced to about half.
Running Windows or Linux well puts Apple in the commodity hardware market and that's what they tried to avoid ever since Steve Jobs came back.
So as a matter of fact they do sell MacOS as a core part of the package and they don't intend for it to be replaceable. Just like they sell iOS. It's not like you can install another operating system on their iPhones and iPads. Those devices don't even belong to consumers that bought them actually. All you're getting is a license to use them.
Apple is definitely not in the hardware business. What they sell is licenses.
This reasoning is overused and wrong.
Apple's hardware is no good for other operating systems, it doesn't run well with either Linux or Windows, the support being shitty due to Apple's proprietary stuff. As an example the experience with the touchpad becomes much poorer and the battery life is reduced to about half.
Running Windows or Linux well puts Apple in the commodity hardware market and that's what they tried to avoid ever since Steve Jobs came back.
So as a matter of fact they do sell MacOS as a core part of the package and they don't intend for it to be replaceable. Just like they sell iOS. It's not like you can install another operating system on their iPhones and iPads. Those devices don't even belong to consumers that bought them actually. All you're getting is a license to use them.
Apple is definitely not in the hardware business. What they sell is licenses.
> So as a matter of fact they do sell MacOS as a core part of the package and they don't intend for it to be replaceable.
Ahhm. BootCamp[0] is an integral part of MacOS for a while. (and before that, for a couple of years, it was a free add-on). It is the apple mandated, supported, sanctioned way to run Windows on a Mac, including needed drivers. Battery life is not quite as good, true.
Your claim that "Apple is definitely not in the hardware business. What they sell is licenses." is contradicted, both by the existence of BootCamp, and by your inability to buy a license without the hardware (and/or at a price that does not include a profit premium on that hardware).
[0] https://support.apple.com/boot-camp
Ahhm. BootCamp[0] is an integral part of MacOS for a while. (and before that, for a couple of years, it was a free add-on). It is the apple mandated, supported, sanctioned way to run Windows on a Mac, including needed drivers. Battery life is not quite as good, true.
Your claim that "Apple is definitely not in the hardware business. What they sell is licenses." is contradicted, both by the existence of BootCamp, and by your inability to buy a license without the hardware (and/or at a price that does not include a profit premium on that hardware).
[0] https://support.apple.com/boot-camp
That you cannot buy a license to MacOS is actually proof for my claims. Another fact is that you cannot run MacOS on non-Apple hardware.
And Bootcamp is nothing more than smoke and mirrors, a checkbox to tick in order for apologists to have amo.
Having used Windows on a MacBook Pro 2016 for two years, my experience has been worse than with a commodity Levono at 1/4 the price.
And Bootcamp is nothing more than smoke and mirrors, a checkbox to tick in order for apologists to have amo.
Having used Windows on a MacBook Pro 2016 for two years, my experience has been worse than with a commodity Levono at 1/4 the price.
>That you cannot buy a license to MacOS is actually proof for my claims. Another fact is that you cannot run MacOS on non-Apple hardware.
Given that you were running Windows on your Mac, I gather that your argument is more one related to the licensing issues of running macOS on non-Apple hardware, rather than an argument that it isn't technically possible. In any case, there is this. Curious how the project will be impacted by these new changes. From the article, it seems that in No Security mode the bootloader may be modifiable in the ways that it needs to be for modifications like Clover to work.
Clover EFI bootloader https://sourceforge.net/projects/cloverefiboot/
Features
Boot OS X, Windows, and Linux in UEFI or legacy mode on Mac or PC with UEFI or BIOS firmware
Boot using UEFI firmware directly or CloverEFI UEFI firmware emulation
Given that you were running Windows on your Mac, I gather that your argument is more one related to the licensing issues of running macOS on non-Apple hardware, rather than an argument that it isn't technically possible. In any case, there is this. Curious how the project will be impacted by these new changes. From the article, it seems that in No Security mode the bootloader may be modifiable in the ways that it needs to be for modifications like Clover to work.
Clover EFI bootloader https://sourceforge.net/projects/cloverefiboot/
Features
Boot OS X, Windows, and Linux in UEFI or legacy mode on Mac or PC with UEFI or BIOS firmware
Boot using UEFI firmware directly or CloverEFI UEFI firmware emulation
I last used boot camp in 2012, and it was fine; buying a MacBook for the purpose of running windows is ... uneconomical, at best. But it does work.
However, could you elaborate on why the fact that you cannot buy an OSX license proves your point that Apple is in the business of selling licenses? I am at loss.
However, could you elaborate on why the fact that you cannot buy an OSX license proves your point that Apple is in the business of selling licenses? I am at loss.
People still buy iPhones and iPads despite the hardware platform lockdown.
In many cases they buy it because it’s a walled garden and locked down. When the alternative is Android it’s not hard to see why. People here seem to miss that while some people want freedom to experiment and play, others want the freedom to just have the device work as intended and not have to worry about fraudulent or malicious apps.
It would be weird if a dev preferred the lockdown, and weirder still if my grandmother didn’t.
It would be weird if a dev preferred the lockdown, and weirder still if my grandmother didn’t.
I’m a Dev and my phone is not my computer. I want a device that “just works” where I can download any random app with abandon and have some type of assurance that an app can’t do crazy things.
I am much more careful about what gets downloaded on my computer but I want to be able to do anything.
I am much more careful about what gets downloaded on my computer but I want to be able to do anything.
> It would be weird if a dev preferred the lockdown
I’m a Dev and I prefer the lockdown, on my daily driver device that is. If it was forced on every device, I’d be opposed, but having it be something I can opt out of on my dev devices is perfect IMHO.
I’m a Dev and I prefer the lockdown, on my daily driver device that is. If it was forced on every device, I’d be opposed, but having it be something I can opt out of on my dev devices is perfect IMHO.
I'm also a dev and I prefer the lockdown. There's plenty of other computing equipment that is not locked down, and the restrictions only really apply to a tiny amount of use-cases. For instance, I would have had no trouble learning to code if I was growing up now on a modern Macbook – or even an iPad. (In fact it would be loads better than QuickBASIC. I am so envious of techie kids now.)
Those serve very different use-cases and were locked-down from the start, unlike Apple's early desktops and laptops (with the notable exception of the Lisa) which, while still not as open as the PC, were comparable, especially when they switched to standard PC architecture a little over a decade ago.
Freedom and secure boot are not mutually exclusive things. The important bit is the ability to enroll your own signing key. See the yellow state in this diagram: https://source.android.com/security/verifiedboot/verified-bo...
Disclaimer: I worked on this.
Disclaimer: I worked on this.
As long as the option to use secure booting stays user-configurable (even if it's opt-out), this sounds like a great way to for example do theft deterrent - if you can mark a specific macbook's serial number as stolen, and thus preventing internet recovery or reinstalls from external media, just like you can with iOS devices today via Find My iPhone, where Apple may deny granting a re-installation AP-ticket for the device's serial number, all the better.
If word gets out to every shady character that stolen macbooks are effectively bricks, perfect.
If word gets out to every shady character that stolen macbooks are effectively bricks, perfect.
Eh. Most (all?) x86 systems with secure boot support loading your own keys for signing/verification. All systems I have that support secure boot are using my own keys to verify the linux kernel before loading it.
It is absolutely scary to me that "my" computer could be running some OS that I don't want it to run. I have no freedom if someone else controls my OS. That's why I run free-software operating systems with secure boot enabled.
Are you aware of the fact that your computer runs a lot of scary code that you can't see anyway? Do you audit the firmware of your drives?
You don't need to verify everything yourself, when the code is open you can trust one or more third party auditing
How did that work out for the HeartBleed bug that was in Open source code for a year?
and since when were device firmwares "open" or audited by a "trustworthy" and "competitive" party?
I work on OneCore (Windows) and sometimes I have trouble believing the kind of crap some hardware vendors ship as firmware.
I work on OneCore (Windows) and sometimes I have trouble believing the kind of crap some hardware vendors ship as firmware.
I am absurdly aware of this. I am also absurdly aware that most free software isn't audited, either, and is full of unintentional security vulnerabilities more exploitable than anything going on with my proprietary firmware. Nonetheless, I believe in incremental improvements.
(Note that untrustworthy drive firmware has an easy workaround at least in theory - just do full-disk authenticated encryption, and then the drive can't do anything worse than DoS you, which is sort of a thing drives tend to do on their own anyway.)
(Note that untrustworthy drive firmware has an easy workaround at least in theory - just do full-disk authenticated encryption, and then the drive can't do anything worse than DoS you, which is sort of a thing drives tend to do on their own anyway.)
So have you personally audited every line of code that runs on your computer? What about the firmware?
I don't know why you are being downvoted: losing the ability to install what we want on our computers is clearly A Bad Thing.
I don't understand what either of your comments have to do with the article. You seem to be assuming some counterfactual implementation of the feature, but the article is quite explicit that these fears are unfounded. There is no loss of the ability to install what you want.
It puts mechanisms in place to deny that in future, however
Because it's not accurate. You can install whatever you want on a system with secure boot.
This is not that - you can still turn it off and boot whatever OS you want.
And so can anyone with physical access to the device. I know there's no way to fully prevent evil maid attacks, but Secure Boot helps in that no one can simply plug e.g. a Linux Live USB and wipe my disks in less than 3 minutes
Really, that should not be possible with secure boot. Secure boot ensures only trusted OSes are run, and those OSes should require authorization before allowing secure boot to be turned off.
Scarier evil maid attacks involve changing hardware or firmware. The personalized version of secure boot mentioned would make that more difficult.
Incidentally, an interesting defense against evil maid attacks involves glitter nail polish. Use it on a sticker over the case and take a photo. To verify your laptop is safe, compare the sticker with the photo. The key is that glitter polish has a lot of minute detail and is thus hard to replicate.
This only gives tamper protection, but evil maid attacks require interaction so it suffices for security.
Incidentally, an interesting defense against evil maid attacks involves glitter nail polish. Use it on a sticker over the case and take a photo. To verify your laptop is safe, compare the sticker with the photo. The key is that glitter polish has a lot of minute detail and is thus hard to replicate.
This only gives tamper protection, but evil maid attacks require interaction so it suffices for security.
Booting into linux from usb and wiping your disk in 3 minutes is not a real threat. It's not even a hypothetical threat. Why not just steal the thing instead or physically destroy it if you want to wipe the disk for some reason? And what reason would that even be, why would anyone want to wipe the disk given physical access? As losing data is something we already expect from mere hardware failures, software failures, operational mistakes, etc., no attackers necessary.
So, no, the whole secure boot thing is just bullshit security theater and more lock in.
So, no, the whole secure boot thing is just bullshit security theater and more lock in.
Digression alert: I'm not talking about MBP-related stuff at all.
> So, no, the whole secure boot thing is just bullshit security theater and more lock in.
Only if you're only thinking about laptops, desktops, maybe phones and tablets. There are lots of types of machines out there physically exposed to users whom the machine-owners trust to varying degrees, ranging from "not at all" on up.
Think UPS package scanners, HVAC systems, various control systems in everything from warehouses to prisons, sensors and signage controls...
Now, Secure Boot doesn't address anywhere near anything close to "sufficient" in any of those environments, but it is one component of raising the costs of attacking them to a point to make the systems economically viable, or at least apparently so.
> So, no, the whole secure boot thing is just bullshit security theater and more lock in.
Only if you're only thinking about laptops, desktops, maybe phones and tablets. There are lots of types of machines out there physically exposed to users whom the machine-owners trust to varying degrees, ranging from "not at all" on up.
Think UPS package scanners, HVAC systems, various control systems in everything from warehouses to prisons, sensors and signage controls...
Now, Secure Boot doesn't address anywhere near anything close to "sufficient" in any of those environments, but it is one component of raising the costs of attacking them to a point to make the systems economically viable, or at least apparently so.
Against the evil maid you are supposed to use SecureBoot together with full disk encryption and TPM.
If someone disables SecureBoot, then the encryption keys become inaccessible and you will notice that something is wrong.
I don't quite understand your wipe the disk thing, since that will leave a trace, the attacker could just smash your computer or take out your drives.
If someone disables SecureBoot, then the encryption keys become inaccessible and you will notice that something is wrong.
I don't quite understand your wipe the disk thing, since that will leave a trace, the attacker could just smash your computer or take out your drives.
Wiping a disk is not a security threat; I can do that from the recovery OS without booting into Linux. What is a security threat is modifying the operating system to contain a backdoor so that it can read from your hard drive when you unwittingly enter your password to unlock the disk.
Don't most bios have a password protect option? That alone makes evil maid attacks significantly harder.
That's the way to go I guess. But secure boot has obvious advantages in comparison. As a rule of thumb I do not trust any client-side "authentication" or passphrase input as long as there's no crypto involved. In legacy BIOS this passphrase can be bypassed easily, for instance
Yes, but it's not either-or, both can be used.
Combined with a TPU that wipes keys when secure boot is enabled/disabled gives a pretty secure system, that still allows you to "eject" to an unsigned boot when needed.
Combined with a TPU that wipes keys when secure boot is enabled/disabled gives a pretty secure system, that still allows you to "eject" to an unsigned boot when needed.
In most Secure Boot-enabled PCs you can manage keys and certificates on the firmware KEK/DB variables by using utilities such as KeyTool, so that you can safely boot any EFI-compliant OS with a custom certificate.
I'm not sure how this would work on Apple devices. It seems to me they have reinvented the whole security infrastructure of their services, which it's not a bad thing, but also requires some serious hacking if you don't want your device locked down with Apple-only software. Is there any way you could possibly manage the trust chain of secure boot on devices with the T2?
I'm not sure how this would work on Apple devices. It seems to me they have reinvented the whole security infrastructure of their services, which it's not a bad thing, but also requires some serious hacking if you don't want your device locked down with Apple-only software. Is there any way you could possibly manage the trust chain of secure boot on devices with the T2?
> some serious hacking
I guess "Reboot into Recovery, Open the Secure Startup Utility and allow booting from external media and Set it to No Security" counts as serious hacking now :)
I guess "Reboot into Recovery, Open the Secure Startup Utility and allow booting from external media and Set it to No Security" counts as serious hacking now :)
That simply disables Secure Boot, which is not what sanlyx wants because you don't get the security benefit of replacing the manufacturer provided PK and/or KEK with your own so that only images you signed will boot.
Sure, you don't get your own secure boot, but the point is, it's not "omg apple lockdown no third party OS possible at all"
What I don't get is this: If Apple wants to introduce "Secure Boot" while also pitching their products to "creative professionals" (who most surely run to their IT departments to pick up their MacBooks fresh off a purchase order) would they really overlook an imaging solution? Surely being the kings of walled garden ecosystem could spin this up in their own solution.
The motivation to prevent imaging is that an attacker can modify the device before it gets to the end user. With MDM, the IT department can audit all of the changes that have been applied post-Apple. And the IT department can use it to apply whatever changes they want to. So the gist of it is it’s “more secure than imaging”. My understanding is that the community hasn’t figured out how to do everything they need to with just MDM/DEP, so some imaging use cases still exist, and the community hasn’t figured out how to apply the MDM/DEP workflows to as many machines as quickly as the imaging workflow.
The "secure" part of secure boot only protects booting macOS, it doesn't safeguard against actors intercepting shipments and dropping malware before the customer performs MDM setup via DEP. E.g. it's trivial to sideload a LaunchDaemon via Target Disk Mode, which the Mac will load on first boot, even with full protection, since FileVault hasn't yet been enabled by the user (or the MDM). Imaging every device that you buy is still the only available protection against this threat. Note that Secure Boot is very much a welcome feature in this scenario, as it also secures the machine's firmware.
Performance is also a factor, as you mention. If you're onboarding hundreds of people in the same room at the same time, there's no WiFi in the world that can deliver the base config in a timely and reliable manner. One solution is to preload all the necessary bits, see for example Facebook's AutoDMG Cache Builder.
Imaging is still also by far the most automatable solution, and the only one that can truly be zero touch. It's possible to reinstall and set up a fleet of machines, with no human needed to touch them. DEP still requires a human with physical access to set up the machine on first boot.
While we've switched to DEP and MDM as our main deployment method, it still has a ways to go before it covers all cases.
Performance is also a factor, as you mention. If you're onboarding hundreds of people in the same room at the same time, there's no WiFi in the world that can deliver the base config in a timely and reliable manner. One solution is to preload all the necessary bits, see for example Facebook's AutoDMG Cache Builder.
Imaging is still also by far the most automatable solution, and the only one that can truly be zero touch. It's possible to reinstall and set up a fleet of machines, with no human needed to touch them. DEP still requires a human with physical access to set up the machine on first boot.
While we've switched to DEP and MDM as our main deployment method, it still has a ways to go before it covers all cases.
It sounds to me like imaging is the solution to attackers modifying systems during shipment.
> Are you someone that needs to worry that a delivered device has been manipulated mid-shipment?
> If you try placing a simple LaunchDaemon on a Secure Boot device’s System volume, it doesn’t stop it from booting in Full Security mode. That’s not one of the things in the signature manifest.
With DEP/MDM the existing OS and files that were there doing shipment would still be there, DEP/MDM would just add additional things or change settings. With imaging you wipe out everything that was there during shipment and start fresh.
> Are you someone that needs to worry that a delivered device has been manipulated mid-shipment?
> If you try placing a simple LaunchDaemon on a Secure Boot device’s System volume, it doesn’t stop it from booting in Full Security mode. That’s not one of the things in the signature manifest.
With DEP/MDM the existing OS and files that were there doing shipment would still be there, DEP/MDM would just add additional things or change settings. With imaging you wipe out everything that was there during shipment and start fresh.
> It sounds to me like imaging is the solution to attackers modifying systems during shipment.
It’s not. They could hack the BIOS or the IME to establish a rootkit that is practically impossible to detect.
It’s not. They could hack the BIOS or the IME to establish a rootkit that is practically impossible to detect.
Then why is the effort not to detect/reinitialize modifications to the BIOS or IME instead of this more complicated alternative?
[deleted]
Which is great, except when the attackers use MDM to compromise your system
https://arstechnica.com/information-technology/2018/07/hyper...
https://arstechnica.com/information-technology/2018/07/hyper...
It sounds like they're pitching for the DEP setup instead. DEP, in combination with post-deploy tools, provides another way to handle device provisioning.
It’s barely workable once you hit a few thousand machines. That being said, most people don’t end up in that situation. Any large company doing IOS CI with 100+ developers however will encounter issues with the demise of network booting/imaging.
If you're an enterprise-ish company, you use DEP which they still support. This only affects companies that have, for whatever reason, chose not to use the solution Apple provides for this.
Cool write-up. This is one of the things that interested me about the new T2 computers; having a secure boot process that loads every link in the boot chain using cryptographic signatures verified by an onboard TPM engineered by some of the smartest people in hardware security. This isn't a move by Apple to lock users into their platform, they do that far more effectively through other means.
It really looks like a boot verification process to restrict which OSes can run on the device, à la iOS, which can only run what is current and signed by Apple.
Looks like Apple's implemented a significant part of the iOS boot chain security model here: I'm seeing AP Tickets, the Tatsu Signing Server (gs.apple.com), and personalization using ECIDs, all of which are part of the signing process for low-level boot on iOS.
By the way, the iPhone Wiki has J137AP down as the iBridge processor, not the iMac Pro itself: https://www.theiphonewiki.com/wiki/J137AP
By the way, the iPhone Wiki has J137AP down as the iBridge processor, not the iMac Pro itself: https://www.theiphonewiki.com/wiki/J137AP
Mods: Title could be amended to mention that this is about imaging solutions for new Macs with Secure boot.
Agree, but maybe the word provisioning is better. I initially interpreted the title as being about booting other OSes from Apple hardware, or perhaps a vuln in their secure boot firmware, but not about provisioning Apple hardware by booting from USB or something.
The security implications and what you do and don’t get out of it from a security perspective are discussed. Like you can drop a launchdaemon on it and that’s not evaluated as part of the system’s integrity. Only the boot process (for now).
How would you drop a Launch Daemon on the device if FileVault is enabled (as it is by default on all new Macs)?
You couldn’t disable it and reenable it?
You'd need the disk password to do that.
I think there’s a misunderstanding here. He’s talking about modification of the Mac between Apple and the customer. I thought you were saying it’s pre-encrypted, my fault for misunderstanding.
Ah. Does this explain why my IT department has frozen all new Mac distributions for the next 6 months because of the T2 chip?
Thanks for the wonderful write-up.
Has anyone heard any more details on how GreyKey bypasses secure boot on the iPhone? Do we know the T2 has fixed that flaw?
There is a command you can run that will allow you to boot and do the restore from Apple. But you definitely need a fast internet connection. If you manage Mac’s you are going to have to sign up for DEP and something like JAMF.
It's simple.
When SecureBoot is done by Microsoft, it's a terrible thing that destroys all freedoms. All hardware with it should be boycotted.
When it's done by Apple, it's a nice security feature, what's your problem?
When SecureBoot is done by Microsoft, it's a terrible thing that destroys all freedoms. All hardware with it should be boycotted.
When it's done by Apple, it's a nice security feature, what's your problem?
The double standards are strong in the software industry.
What you've never seen a hypocrite before? ;)
Just look at amount of comments on Apple threads concerning their eager assistance to Chinese regime and amount of comments declaring Apple hardware as the second coming of the messiah in all other hardware threads.
Just look at amount of comments on Apple threads concerning their eager assistance to Chinese regime and amount of comments declaring Apple hardware as the second coming of the messiah in all other hardware threads.
Can you link to the instructions for disabling SecureBoot on microsoft ARM devices?
Same place as the instructions for disabling Secure Boot on Apple ARM devices.
These corporations are big enough that it makes little sense to say "corporation good" or "corporation bad" (and it also doesn't provide any incentive for the corporation to change). If we say "Enforced bootloader signature verification with the ability for the physical device owner to enroll keys is good" and "Enforced bootloader signature verification without that is bad," that applies equally well to both MS and Apple.
These corporations are big enough that it makes little sense to say "corporation good" or "corporation bad" (and it also doesn't provide any incentive for the corporation to change). If we say "Enforced bootloader signature verification with the ability for the physical device owner to enroll keys is good" and "Enforced bootloader signature verification without that is bad," that applies equally well to both MS and Apple.
I tend to agree about "feature good, feature bad".
But corporations ("are people" and) it definitely makes sense to say they are "good" or "bad", just as you can say that about people.
Microsoft, for decades, bullied everyone around and kept pissing into the collective village well, e.g. with their stacking of ISO committees towards standardizing OOXML, which later slowed down ISO processes to a stop because of the many never-present-never-voting-except-that-one-vote members (and those processes are not quick to begin with). I have over 20 years of bullying stories between 1990-2010 or so, some of which I was personally involved and affected by.
They have been beat into submission in the last few years, and are now behaving in line with a "good corporate citizen" behaviour. If they continue that for twenty years, I might consider them reformed.
Holywood/MPAA are a "bad corporation" for their work on the public domain. Oracle are a "bad corporation" for anyone who likes open systems. Google is a "bad corporation" for anyone who likes privacy. Facebook is a "bad corporation" for almost any group. I'm sure Apple is too, but I haven't met anyone who has been affected by Apple's policies except of being a direct competitor, so I'm not sure how that group looks.
All of these companies do deliver useful services, of course. But they do that for profit (which is what a corporate does). And while doing that, to grow, they inflict great harm on the ecosystem at large, much larger than the benefit and profit they derive from causing that harm. I guess that's one definition of a "bad actor" in my book.
But corporations ("are people" and) it definitely makes sense to say they are "good" or "bad", just as you can say that about people.
Microsoft, for decades, bullied everyone around and kept pissing into the collective village well, e.g. with their stacking of ISO committees towards standardizing OOXML, which later slowed down ISO processes to a stop because of the many never-present-never-voting-except-that-one-vote members (and those processes are not quick to begin with). I have over 20 years of bullying stories between 1990-2010 or so, some of which I was personally involved and affected by.
They have been beat into submission in the last few years, and are now behaving in line with a "good corporate citizen" behaviour. If they continue that for twenty years, I might consider them reformed.
Holywood/MPAA are a "bad corporation" for their work on the public domain. Oracle are a "bad corporation" for anyone who likes open systems. Google is a "bad corporation" for anyone who likes privacy. Facebook is a "bad corporation" for almost any group. I'm sure Apple is too, but I haven't met anyone who has been affected by Apple's policies except of being a direct competitor, so I'm not sure how that group looks.
All of these companies do deliver useful services, of course. But they do that for profit (which is what a corporate does). And while doing that, to grow, they inflict great harm on the ecosystem at large, much larger than the benefit and profit they derive from causing that harm. I guess that's one definition of a "bad actor" in my book.
For laptop-style devices it's in the firmware configuration. For phones, well, can you link to the instructions for disabling it in iPhones?
Microsoft's restrictions here are abhorrent, but they're also not outside the industry norms. The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
Microsoft's restrictions here are abhorrent, but they're also not outside the industry norms. The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
> For laptop-style devices it's in the firmware configuration.
The discussion in https://news.ycombinator.com/item?id=15855195 indicates that, as of 7 months ago, this was not the case if those laptop-style ARM devices (the linked policy on microsoft's website is now 404).
> The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
It included Surface RT with keyboards, which were esentially laptop-style, at the point in time where Microsoft was still expecting other manufacturers to adopt RT (IIRC there were even a couple of samsung laptop models, quickly dropped).
The discussion in https://news.ycombinator.com/item?id=15855195 indicates that, as of 7 months ago, this was not the case if those laptop-style ARM devices (the linked policy on microsoft's website is now 404).
> The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
It included Surface RT with keyboards, which were esentially laptop-style, at the point in time where Microsoft was still expecting other manufacturers to adopt RT (IIRC there were even a couple of samsung laptop models, quickly dropped).
[deleted]
Maybe Apple users are not as concerned about being able to run other OSs, but there was a huge uproar a few years ago when secure boot was first introduced to PCs. Fortunately you can still turn it off, but its removal may be associated with an ostensibly compelling argument: "why would you not want security?" The answer to that can also be summed up in one word: freedom.