Hacker News Reader

I am well aware none of it will actually happen but nonetheless it would get more people to buy into what seems to be an excellent hardware platform.

Apple had a record Mac quarter (July-September), generating a little over $9 billion in revenue; Mac sales were up 37% from the year before.

A lot of this was due to people buying Macs to WFH during the pandemic. But it also shows they don't have to change what they've been doing to keep sales going.

I suspect when Docker gets running on M1 Macs, a lot of the need to boot into Linux will dissipate. Same thing when Linux running in a VM on Apple Silicon Macs is much faster than any comparable PC hardware you can buy.

Remember, they demoed Debian running in a VM on a prototype M1 Mac nearly 6 months ago, so we know it's coming.

And while I get it—I used to help support a lab of triple-boot Macs (MacOS/Linux/Windows)—being able to boot 3rd party operating systems on manufacturers machines is going to become less common.

With the goal is to diminish the attack surface for the bad guys, my hope is Apple's hypervisor technology will enable access to enough things to create a fast, workable VM solution for 3rd-party operating systems on M1 Macs without sacrificing security.

Yes, without drivers for the SoC and other Apple hardwares, we may only have hackintosh kind of OSes on these ARM Mac.

Moreover, you have to cripple your own macOS to run others OS, which seems a deliberate design to discourage users:

> Permissive Security: Does not enforce any requirements on the bootable operating system. Note: The Permissive Security option appears only when System Integrity Protection (SIP) is disabled. To disable SIP, start up your Mac in macOS Recovery, open Terminal, then run the command csrutil disable.

Disabling SIP doesn't cripple macOS.

It simply affords you the same level of security enjoyed on macOS up to and including 10.10 (Yosemite) -- which was state of the art until July 9, 2018.

Are Windows and Linux insecure? They don't have anything like SIP. Also, the whole idea of SIP has a strong https://xkcd.com/1200/ vibe.

Windows has Windows Resource Protection (previously known as Windows File Protection) with same goals as SIP.

SELinux for Linux can achieve similar levels of protection.

Windows Resource Protection doesn't prevent code injection, and can be disabled from within the OS. I don't consider them equivalent.

It's worth noting that macOS without SIP is a bit more permissive than Windows—it allows you to load unsigned kernel extensions, for instance, whereas 64bit Windows will not load unsigned drivers†.

But I generally agree—power users should feel fine disabling SIP.

Disabling allows you to run dtrace...

On Apple Silicon, you may lose access to e.g. Touch ID login to websites and Apple Wallet, as Apple’s Touch ID protocol allows^ websites to require a secured+unmodified system partition and Wallet may require the same for anti-fraud purposes. I expect Steam VAC and Xbox cross-platform multiplayer will take note of this someday, too.

This relates closely to the likelihood of future PCs with Microsoft Pluton^ firmware as well. I assume that Microsoft saw the writing on the wall about secure OSes and remote education and online testing and is repurposing their Xbox anti-tampering system for Windows before they get locked out of that market by Apple Silicon.

It’s not about disallowing you from tampering, or about blocking third-party operating systems — it’s about attesting whether or not you are able to tamper, in scenarios where a remote third-party has no physical access to your system. The Linux secureboot shims probably will not be sufficient to earn ‘tamperproof’ as they boot arbitrary unsigned code with tamper-capable privileges via /sbin/init or whatever.

^ via crypto-signed attestations by the Apple firmware+OS, working in tandem to attest that the stack is not and cannot be tampered with as currently booted.

^ https://news.ycombinator.com/item?id=25123990

EDIT: Apologies, the missing paragraph connecting to the parent comment is —

IT departments will begin updating SSO/MFA systems to require, when deployed hardware permits it, the tamperproof attestations. This will protect them from the liability risk of employees turning off key security protections such as SIP, and may result in Apple Silicon being widely adopted by sensitive industries such as banking and IT once they realize they can reduce their risk and liability insurance costs by doing so.

So SIP isn't about keeping me secure. It's about keeping my computer secure from me.

Keeping you secure requires keeping the computer secure from attackers. You can't be distinguished from an attacker, from the computer's perspective. Having the computer be able to attest that it's unmodified means that it doesn't have to mistrust you so aggressively, relative to today.

Requiring a reboot to rescue mode to disable SIP is sufficient to block most social engineering attacks that would otherwise have you click through dialogs to bypass it. A dedicated attacker can still overcome this, and once they do, they can impersonate you readily.

If the computer can attest that it's unmodified, then it's possible to throw up alarms for non-expert users when their computer is in that state. I don't think most websites will bother, but those that care sure would love to be able to do so. None of this is specifically for the benefit of users who want to hack the software internals of their computers, though — but those are not the target market for security practices today in any case, since they can overcome literally any barrier prior to this that says "please secure your device before entering".

Still, from an IT standpoint, it sure would be nice to find out how many expert technical users are lying about keeping their system in secure mode when they have privileged access, because they don't think it's necessary and they don't see any harm in lying about it. I'm guessing it's something like 10-20% of all IT admins using unmanaged devices. We'll find out soon enough!

> You can't be distinguished from an attacker, from the computer's perspective.

Then what's the point of things like passwords and fingerprint scanners?

> Having the computer be able to attest that it's unmodified means that it doesn't have to mistrust you so aggressively, relative to today.

How so?

> Requiring a reboot to rescue mode to disable SIP is sufficient to block most social engineering attacks that would otherwise have you click through dialogs to bypass it. A dedicated attacker can still overcome this, and once they do, they can impersonate you readily.

We need to lock people out of their own computers to protect them from social engineering?

> I don't think most websites will bother, but those that care sure would love to be able to do so.

In practice, this will end up just like the abomination that is SafetyNet on Android, where if you take control of your own device, you can't use Netflix, Snapchat, Pokemon Go, Super Mario Run, Android Pay, etc.

> keeping their system in secure mode

Really? "secure mode"? What kind of attacks specifically would this prevent that an IT department would care about, as opposed to Hollywood/RIAA/etc. caring about?

You’re already familiar with the difference between passwords and secure computing platforms, as evidenced by the citation of SafetyNet and Pokémon Go, and your use of the phrase “abomination” leaves no opportunity for further discussion, so I will stop now to avoid wasting any more of your time. Apologies and be well.

This is already here, Apple[0] can report to a MDM whether or not SIP is enabled, and then Microsoft's Intune[1] can use this to allow or deny access to corporate resources (similar to some stuff that Google had in the BeyondCorp paper).

0: https://developer.apple.com/documentation/devicemanagement/s...

1: https://docs.microsoft.com/en-us/mem/intune/protect/complian...

Based on the presentation from WWDC, each OS partition can have a different security policy.

> Make a downloadable Ubuntu ISO with drivers and firmware integration available that works as a fully functional alternative OS

If Apple were to do it, it would make a lot more sense to release a version of Darwin with all the drivers.

This system seems to only have an "Apple secure mode" of sorts, & a gradient of less secure modes.

In contrast, in the regular PC ecosystem, there's what seems like a reasonably effective user-empowering situation, SO FAR, where computers have been coming with UEFI Secure Boot[1] for over half a decade. I don't fully understand what is required to generate secure boot images & possible foibles or potential confounding factors, but it's seemed like the base requirements[2] include the system advertising it's core "platform key" & allowing users to create their own securing keys based off this, to upload those keys, & there-by allow user-signed images to boot, securely. One of the best guides to this all is the NSA's[3].

The contrast is that Apple seemingly let's one disarm the boot security system, where-as Secure Boot, so far, has allowed users to put the security system to work as they please.

Worth mentioning Chromebooks. I'm even less familiar with the particulars of their boot system, but they most-often have a "developer mode"[4], which disarms the OS protection mechanisms allowing one to install whatever onto the system. Fun fact, on Chromebox systems, this either is or was often achieved by opening the case & removing a specific screw. Once developer mode is enabled, the system will at boot-up show an image notifying the user that the system is insecure, & will boot unsigned code & allow modification to the drive.

And worth mentioning Android! You the user almost never have power over your system. Once your device is no longer maintained, throw it away, because there's nothing you can do to it & in an unmaintained state it is almost certainly insecure. Maybe some intrepid hackers will have found some exploit to bypass the protection mechanisms, and maybe, maybe, you bought one of the probably <1% of devices that still has an unlocked bootloader, and in these exceptional cases you can probably get your own well maintained OS like LineageOS on your device, but for most people, you have no control & can do nothing to your device that is not approved, and the security system is very much designed to keep you out of your own device.

> However without the specifications for the security chip, GPU, SoC - running anything on it is practically meaningless

I'm having similar thoughts about Microsoft's recent announcement, that they have partnered with Intel, AMD, and Qualcomm to get their custom Pluton security chip[5] embedded in seemingly most major cpus going forward. Where-as Google begot an "open source root of trust" system based around the open hardware RISC-V chip[6]- something that can be inspected, checked out, & deployed in new designs gratis- Microsoft seems to be relying on a high degree of trust in their systems & engineering & how that will ultimately empower and/or exclude the user. This new silicon we expect almost literally everywhere comes at a time when Microsoft is about to make a critical requirement of many of the Secure Boot technologies that have been building[7], with a January 1st deadline for Secure Boot support.

Also worth pointing out some of the secure-boot related "whoopsies" that have happened[8][9], recently, & further back.

Overall, all this flurry of activity around securing that's happened so quickly has made me prsonally a little nervous, a bit on edge. Thusfar UEFI Secure Boot has seemed to continue to give the user respect, power over their system, & been quite ahead of the pack in doing so. But it's intimidating how much we are taking on faith, hoping that we continue to retain access. The glossy media-blitz PR of Pluton was ultra-light on technical details; that was intimidating. I want to believe the PC platform continues to be a place for open innovation & where users have the power to maintain their systems & keep control over them, if they want to do so, and in all likelihood Secure Boot and whatever Pluton ends up being probably will continue to help us in that. But it always feels like the keys could be snatched away, that someone could make some decision, & PCs could close off, like so vary many other platforms.

Notably also, to my understanding, UEFI Secure Boot does not require users to be able to remove the systems signing keys, so Microsoft & the manufacturer will retain access to the boot layer of your system no matter what. (I'm not sure about this.)

[1] https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_In...

[2] https://docs.microsoft.com/en-us/windows-hardware/design/dev...

[3] https://media.defense.gov/2020/Sep/15/2002497594/-1/-1/0/CTR...

[4] https://chromium.googlesource.com/chromiumos/docs/+/master/d...

[5] https://www.microsoft.com/security/blog/2020/11/17/meet-the-...

[6] https://techcrunch.com/2019/11/05/google-opentitan-secure-ch...

[7] https://redmondmag.com/articles/2020/06/11/windows-server-ha...

[8] https://www.computerworld.com/article/3528302/the-mess-behin...

[9] https://www.zdnet.com/article/microsoft-secure-boot-key-deba...

I completely agree with you on UEFI - PC vendors mostly have really done the right thing vis-a-vis Secure Booting Windows with MS keys and Linux with custom MOKs.

Keep in mind anything Intel does with their CPUs and GPUs has historically been Linux compatible for the most part - that's just the way the market has been. So it is not far fetched to assume whatever MS is doing with Pluton would at the very least not prevent Linux or BSDs from booting on x86 hardware. And with the Microsoft of today they might even release the specs - after all there is talk about Pluton being used in Azure - and Linux/BSDs can benefit from it too.

An M1 MBA running Windows 10/ARM? I'd buy that right now!

Who would write the Windows drivers for the M1 SoC?

That would have to be Apple just like Bootcamp. It's not just drivers - there's also bootloader and firmware.

Bootcamp very much belonged to a different era where having access to Windows apps was important in particular in the enterprise space.

These days everything has moved to mobile and web apps that I can't imagine they will bother investing the substantial effort to port the drivers across. Especially since Microsoft doesn't seem to take Windows RT all that seriously.

People hacked Windows onto early Intel Macs before Apple made it official with Bootcamp!

> People hacked Windows onto early Intel Macs before Apple made it official with Bootcamp!

Slightly different there though, considering that the early Intel Macs were more or less identical to contemporary PC laptops internally other than the lack of BIOS compatibility mode.

Drivers would be much more challenging in this case.

Microsoft should offer to fund the driver development – either develop the drivers themselves, or pay Apple to do it (this assumes that Apple would be willing to cooperate with either option.)

Getting Windows ARM to work on Apple hardware would do a lot to build mindshare on Windows ARM and contribute to the success of Windows on the ARM platform.

Microsoft needs this much more than Apple does.

Would Apple need to cooperate in the situation where Microsoft was developing the drivers? I'm sure documentation would be helpful, but in the event that Apple doesn't give it... I don't know. Seems to me it would make sense for Microsoft anyway.

Well, they probably could reverse engineer how any Apple-specific devices work, in the absence of documentation or other assistance from Apple, but the added difficulty of doing that may put them off it. So whether Apple is willing to cooperate may be decisive in practice.

I don’t think Apple would really gain anything by refusing cooperation, especially if Microsoft were willing to pay for it. Only a small number of customers will be interested in running Windows on Macs, and Apple gets just as much money from a Mac running Windows as from a Mac running macOS