macOS 27 Beta breaks the ability to boot Asahi Linux
phoronix.com257 points by josephcsible 3 days ago
257 points by josephcsible 3 days ago
https://social.treehouse.systems/@AsahiLinux/116719749555082...
Apparently fixed already, or will be fixed soon. https://social.treehouse.systems/@chaos_princess/11672546441... So it was unintentional behavior in a beta release? Yeah that definitely does feel like something we should be getting up in arms about 404 Works here, here's the text for anyone who can't access it: > Turns out APFS has an undocumented "VolBootable" flag that we were never setting since, well, it is undocumented, and the boot picker never cared about it (it read it and printed it's state to system log, just did not take any action). Anyway, fix PR-ed to asahi-installer, old installs will have an installer option to set the flag. But still, probably hold off on installing macos betas :P. It seems like this is a bug, apple went through the trouble to allow something like asahi to be possible in the first place. I doubt they're purposely trying to break it. Apple designed a bootloader for Apple Silicon Macs that allows you to run an unsigned OS without degrading security when you boot into MacOS. This wasn't an accident. Macs have always allowed you to run another OS. iDevices have always had a locked bootloader. People shouldn't confuse the two. M series macs are weird tho, yes the bootloader allows it but absolutely no documentation on the hardware, drivers etc. Can't help but to think the goal of this wasn't to actually allow third-party OSes, but for development purposes(and ye they could hide the feature behind apple account with paid dev license) or anti-anti-trust measures à-la Google with Firefox: in front of a jury of normal people they can simply say "look there's these nerds making Asahi" the same way "look we're not a monopoly Firefox has .2% market share". > M series macs are weird More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over? > Can't help but to think the goal of this wasn't to actually allow third-party OSes Apple has explicitly stated that allowing third party OSes is exactly the purpose of the new bootloader. I don't know about Intel ME but AMD PSP is basically the equivalent of Apple's Secure Enclave, so there's that. You should probably do do some reading on the subject to gain a bit more understanding: > This puts [Apple Silicon Macs] somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even old ThinkPads). https://asahilinux.org/docs/platform/introduction/ The Secure Enclave is equivalent to a PC's TPM (a TPM is now required to run Windows) not any form of a management engine. > The Secure Enclave is equivalent to a PC's TPM AMD PSP is little more than an embedded TPM. The capabilities are significantly different vs. Intel ME. > AMD PSP is little more than an embedded TPM Again, you've got some reading to do. > the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response". Critics worry it can be used as a backdoor and is a security concern. https://www.wikipedia.org/wiki/AMD_Platform_Security_Process... Now explain to me how Apple's Secure Enclave does not do this: > the subsystem is "responsible for creating, monitoring and maintaining the security environment" and "its functions include managing the boot process, initializing various security related mechanisms, and monitoring the system for any type of activity or events and implementing an appropriate response". It implements TPM or something similar. It is used in the boot process for a secure boot chain. And the last generic point is probably just that it implements the hardware random number generator for the CPU, which Secure Enclave also does (in a different way). I could worry about Secure Enclave being used as a backdoor and being a security concern, too. Doesn't mean it actually is! Yes, more weird than that. x86 PCs have fairly standardised boot and autoconfiguration (UEFI and ACPI). ARM based systems, including the Apple M series, don't. You just have to know what's there (device trees), and Apple isn't going to tell you. Hence why it's difficult to make another OS run on it, because you first need to find out what hardware's even there, and how to talk to it. It's initialised by Apple before iBoot runs, sure, but you don't even know what it is, so good luck writing a driver for it. The Intel ME / AMD PSP are creepy, and probably a security risk to the device owner, but they're not weird, you can run an OS without even knowing they're there, and they like it that way. Asahi Linux already does use an open source UEFI implementation (U-Boot) to boot Linux. https://en.wikipedia.org/wiki/Das_U-Boot The Asahi installer will also allow you to install UEFI alone, in case you want to use UEFI to install some other OS. The hardware management engines in modern x86 chips are backdoors running at a higher privilege level than the installed OS's kernel. It's hard to see them as anything else. Apple's Secure Enclave and ARM's Truszone work the same way as Intel ME and AMD PSP. All of them have a separate specialized minimal OS running on a specially protected memory that cannot be accessed by the normal OS. Apple can lock your Mac just like other manufacturers can do via Intel ME. All of them are backdoors. >ARM based systems, including the Apple M series, don't. You're thinking of old SBCs, most likely. ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) have +/- same level of auto-configuration and hardware resource discovery as x86 PCs. > ARM SystemReady devices (which is a requirement for Thunderbolt 4+ on ARM, so Macs are included) Either this is untrue or misinterpreted - the SystemReady DeviceTree band (the only one Macs could possibly fit into, given they don't implement ACPI) still requires that devices implement EBBR, which requires that devices implement UEFI. Macs don't, and so are very much not SystemReady compliant. >More weird than the opaque Management Engines on Intel or AMD chips that can take full control of your system at any time that you have no control over? Considering they're pretty much fully undocumented (officially, that is) and could contain any number of IME equivalents since we know that they already have independent processors like the secure enclave running its own OS: yeah, probably more weird. Just because Asahi did not find one doesn't mean it doesn't exist. I think they are wary about macOS becoming a designated DMA gatekeeper, it would certainly be very close to the user and income thresholds. The design of the exposed mechanism is explicitly about booting unsigned versions of MacOS. There is zero support for booting anything else, but no enforcement that it must be MacOS. However, apple's justification for exposing this mechanism to users appears to explicitly include "booting linux" even if the mechanism has zero explicit support for booting linux. And if Apple were going to change their mind and try to block linux, they would intentionally modify the bootloader to remove that functionality, not break the boot picker. IDecices should absolutely be treated as laptops and desktops which allow another OS to run on the device. This why I have not bought an Apple device for years. EU is the only governing body that would push owning the device you _buy_. Unfortunately their seem more geared moving to a surveillance state at the moment with chat control. I have fond memories in the early 2000s of getting the first MacBook Pro's with Intel Core i7's and the first thing we did at my company was build and install gentoo. If they allowed something similar on iphones, I'd switch to an iPhone the day an alternate os worked well enough for daily use. why? In my mind the appeal of the iPhone is iOS. The hardware is nice, but so is the hardware of certain Android phones. I think it would be nice if we could run unsigned apps on iOS (in the US), but booting your own OS on an iPhone is a whole different story They're different for now, but it's frog-boiling. Apple has been steadily adding more and more hoops to the process for Macs, and eventually they are going to end up as locked down as iPhones. You get clicks for "Apple bad", not for "there was this boot flag and once we figured that out problem solved". It's Apple's bootloader. They were the ones that chose to use iBoot and not implement UEFI-style booting like prior Macs. ...why would they, this is a strict improvement with less surface area Because it was a featureset they supported without trouble on prior Macs? The onus is on Apple to not make iBoot suck, they don't get a free pass for Microsoft-level boot volume ignorance. Such bugs have happened and been reported before. Asahi exercises "raw boot" facilities that just don't get all that much attention in any other context. >apple went through the trouble to allow something like asahi to be possible in the first place if going through trouble means "doing less shit to lock their systems down", then yes. Apple ultimately dgaf about linux. (removed) If the happy path disappears, the not-so-happy path will be taken to allow for booting custom kernels, one that will likely rely on turning the some or a lot of the RE energy towards breaking the Secure Enclave, the bootloader, and so on. Apple practically laid the red carpet out to avoid people trying to crack the parts of the hardware/software chain-of-trust they would really rather not have cracked. A similar strategy helped keep the Xbox One un-pwned for over a decade (running homebrew was allowed in a specific mode). It is doubtful Apple's legal department isn't aware of the value of the current software strategy. So isn't that just purely security by obscurity then? Would they not rather have someone publicly break it instead of selling a zero day? Nothing is perfectly secure on its own. No system designed or checked by humans ever will be. After all, the Xbox One was indeed pwned, relatively recently. However, because the juice wasn't worth the squeeze for so long, it got pwned years after it was a relevant, money making console. Novel jailbreaks for ancient iPhones are not worth much. But attention on current, brand new devices means increasing the danger that a mistake gets found, which increases the odds that that mistake is found by someone who wants to sell it for the most money. Also, from Apple's perspective a zero-day in the bootloader on macOS also means a zero-day in the bootloader in all of the billions of iOS devices out there too. They do not want to give anyone anymore reason than what already exists to try and pwn LLB or iBoot. Given a happy path, all of that hacker energy for "put Linux on my M1 Macbook" is put towards device drivers and support, rather than "how the hell do we get an alternative kernel booting on this thing". Fewer bullets pinging off the armor. Fewer cracks in the fuselage forming. Fewer knives to dodge. All of it means Apple's boot process for their current devices are less likely to be pwned before they turn into e-waste (whenever that is, not making a comment on Apple's perhaps accelerated or otherwise practices in obsolescence). Just like a jetliner will eventually succumb to entropy and become dangerous to fly, so too will a lot of "secure" software. You only need to actively maintain a jetliner while it is flying passengers or cargo. Once it is retired, it can rot, people can break into the husk of it at the junkyard and fornicate and smoke crack and smash windows and steal parts of the fuselage. At that point, who cares? No, if their lawyers want it gone, Apple will just update the bootloader to reject local signing keys. The actual problem was that Apple has an undocumented APFS key for if a volume is bootable, which Asahi wasn't setting and Apple wasn't checking, but now they do, so they do. The comments there are absolutely insane lol, especially now that we know it's a bug. I did not realize that some people were still so anti-Apple. I'm of course not saying that there's not a small element of truth in many of the comments, but talk about some straw man arguments. I did not realize all the tech companies had completely changed their behaviors to be granted the benefit of the doubt. Sure they don't do EVERYTHING we think they do, but they do so much, and so much more we DON'T know about... Anyway, Apple could help the Linux team in months to close huge amounts of functionality gaps but ... they don't. Sadly both main ARM platforms (Apple silicon and Qualcomm) are a mine field for Linux Most computers have been like that, FOSS got lucky that IBM failed to secure the PC for themselves, thus the PC clones. When folks say Intel and AMD are done, and we should all be on ARM, or RISC-V, beware of what to wish for. Yes there are device trees now, however someone has to keep them up to date, and that is only part of what makes a motherboard. I have said it for a while, Microsoft's business strategy was probably the best thing that ever happened to Free/Open software. They were ones pushing for more open systems so that they could sell DOS and Windows to other vendors. yes, it left the door open for others but they also figured they could push their software far harder than others could. I agree with the ARM/RISCV stance that we should be cautious with what we ask. I have seen some RiscV providers in China are starting to push for a BIOS compatible boot system which is great to see, but there is no guarantee that it will be adopted or it will last for long. Other than this situation, what other landmines are there? I have an M1 with Asahi Arch Linux that I've been using as my primary laptop for the last 8 months, its my favorite laptop by far out of the 5ish I have. Pretty much all ARM platforms are. Even ARM devices designed from the ground up to be Linux devices are full of issues, like the MNT Pocket Reform's lack of HW suspend. The tight interop between vendor and implementation is a huge anti-pattern for software freedom, and the standardization initiatives like ARM SR are nowhere to be seen. It's probably the most problematic part of ARM being the future of personal computing, yet another impending manifestation of enshittification. i run linux on both in arch and fedora versions with zero problems, by using the hypervisor framework of macos and wsl2 (wrapper for hyperv). do you need a more direct than hypervisor access to some hardware? A lot of us would prefer MS/Apple to never be within touching range of our hardware. On the other hand, your “us” is not very big compared to your “not us.” I like Linux as a server OS (and would pick it over Windows or MacOS for that any day of the week that ends in y), but as a desktop OS it’s just more work than I care to exert (in fact, Windows also exceeds my tolerance for fiddliness in a desktop OS). My general preference is for “you don’t have to” over “you can” as much as possible which is the exact opposite of the Linux desktop experience. macOS and Windows are both such a chore for development, though. WSL was the closest I got to an "it just works" dev environment, but it exposes just how bad native toolchains like Cygwin and git bash are. macOS is hardly any better, and once you manage to install all of the GNU utilities it just feels like a poorly-supported Linux distro. It's a bunch of wasted effort to imitate a fraction of Linux's power. So what are we supposed to use? ReactOS? SerenityOS? The entire mainstream is a "you have to..." OS, I fear the day when I have to abandon GNOME for a desktop that treats developers like chopped liver. Your general preference is fine, but I'm surprised that it aligns with the OEMs that want to put advertisements all over your desktop. > it just feels like a poorly-supported Linux distro. That's because it's Unix, not Linux. macOS, as shipped, is only Unix-like. Even when configured to pass UNIX certification, it doesn't qualify without the temporary waivers: [1] https://www.osnews.com/story/141633/apples-macos-unix-certif... As an aside: > ... copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin ... This should be your hint that UNIX certification is more of a box-checking exercise than a real test of functionality. UUCP has been functionally obsolete since at least the mid-1990s; it's surprising that macOS even bothers shipping its binaries, and it's exceptionally silly that UNIX certification requires it to be present and installed in /usr/local. It doesn't look like the certification requires those UUCP binaries to be in /usr/local, that's just where you have to put them on macOS to be able to `chmod +s` them, which is what the certification actually requires. Less arbitrary, but even more clearly obsolete and bad practice for a modern OS.
AKSF_Ackermann - 10 hours ago
SOLAR_FIELDS - an hour ago
himata4113 - 7 hours ago
Chu4eeno - 7 hours ago
vsgherzi - 2 days ago
GeekyBear - 10 hours ago
hollow-moe - 9 hours ago
GeekyBear - 8 hours ago
Rohansi - 8 hours ago
GeekyBear - 7 hours ago
Rohansi - 3 hours ago
GeekyBear - 2 hours ago
Rohansi - 4 minutes ago
amiga386 - 8 hours ago
GeekyBear - 6 hours ago
okanat - an hour ago
antonkochubey - 4 hours ago
mjg59 - 4 hours ago
well_ackshually - 7 hours ago
benoau - 8 hours ago
phire - 8 hours ago
phire - 9 hours ago
yndoendo - 3 hours ago
reactordev - 2 hours ago
nosioptar - 9 hours ago
br0wnr1c3 - 4 hours ago
josephcsible - 5 hours ago
kjs3 - 6 hours ago
bigyabai - 5 hours ago
throawayonthe - 5 hours ago
bigyabai - 4 hours ago
zozbot234 - 9 hours ago
ActorNightly - 4 hours ago
amelius - 10 hours ago
wpm - 10 hours ago
CjHuber - 9 hours ago
wpm - 6 hours ago
kmeisthax - 10 hours ago
inventor7777 - an hour ago
AtlasBarfed - an hour ago
grigio - 2 days ago
pjmlp - 9 hours ago
HerbManic - 4 hours ago
KetoManx64 - 2 days ago
ux266478 - 9 hours ago
jjtheblunt - 10 hours ago
officeplant - 9 hours ago
dhosek - 9 hours ago
bigyabai - 8 hours ago
nomel - 7 hours ago
bigyabai - 7 hours ago
Maybe your installation of macOS is technically Unix, but mine sure as hell ain't. Desktop "Unix" in 2026 is little more than lipstick on a pig anyhow. if you want your installation of macOS 15.0 to pass the UNIX® 03 certification test suites, you need to disable System Integrity Protection, enable the root account, enable core file generation, disable timeout coalescing, mount any APFS partitions with the strictatime option, format your APFS partitions case-sensitive (by default, APFS is case-insensitive, so you’ll need to reinstall), disable Spotlight, copy the binaries uucp, uuname, uustat, and uux from /usr/bin to /usr/local/bin and the binaries uucico and uuxqt from /usr/sbin to /usr/local/bin, set the setuid bit on all of these binaries, add /usr/local/bin to your PATH before /usr/bin and /usr/sbin, enable the uucp service, and handle the mystery issues listed in the four Temporary Waivers. [1]
duskwuff - 6 hours ago
wtallis - 6 hours ago