macOS 27 Beta breaks the ability to boot Asahi Linux
phoronix.com
phoronix.com
> 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.
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?
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.
Macs have always allowed you to run another OS.
iDevices have always had a locked bootloader.
People shouldn't confuse the two.
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.
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.
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 can lock your Mac just like other manufacturers can do via Intel ME. All of them are backdoors.
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.
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.
> 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.
AMD PSP is little more than an embedded TPM. The capabilities are significantly different vs. Intel ME.
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...
> 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!
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.
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.
If you're using an unstable API they expect you to figure everything out yourself. It doesn't mean that they don't want you to use it though.
Could also be pretending to be open while making sure nothing dangerous actually gets made.
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
Apple enforces those restrictions via the permanently locked bootloader. The main benefit of unlocking the bootloader on an iPhone would be to run a modified version of iOS that allows for the installation of unsigned apps. Apple wouldn't like it and might even get litigious over it, but still.
> (in the US)
Apps intended for release onto alternative app stores in the EU, Japan, and Brazil still need to be approved and signed by Apple. These laws were nearly useless.
Really, all I want from a phone is to be able to run Linux/xfce on it.
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.
Then Office and IE were ported. It was so weird running Word on a Mac. It was a good port too. They did a good job of embracing Mac UI ideas. I found the Mac Word better than Win Word.
I was kind of new to the Mac back then.
I imagine Apple donated a bunch of early OS 10 machines to MS for development. I wonder if the MS Mac Dev team was a pariah at MS.
The onus is on Apple to not make iBoot suck, they don't get a free pass for Microsoft-level boot volume ignorance.
Because of this lack of documentation, every release of a new version of Apple hardware or software may require the restarting of the reverse engineering work, like in this case, just to keep working the alternative operating system.
Rather than blaming Apple for this, the correct approach would have been to post something like "if you dual boot Asahi, don't upgrade to macOS 27 until you've done this".
The "correct approach" is "Apple doesn't support Linux on M-series processors. If you're not willing to accept shit breaking regularly and having to do (much more likely, relying on other people without compensating them) the actual work to RE Apples ever-changing stuff then don't buy hardware that explicitly does not support the OS you want to run. If you want 'plug-and-play', you are barking up the wrong tree." This really isn't hard.
Back in the heyday of Hackintosh, there was always someone who wandered into one of the forums to shittalk Apple for not supporting some chunk of hardware they owned but Apple never shipped (usually with some whining to the effect "Windows supports my knock-off of a knock-off Alibaba special and it's totally unreasonable that unsupported MacOS on unsupported hardware doesn't Just Work!"), but I don't recall the adults in the room giving that sort of nonsense the time of day other than to say "here's the stuff that we know works...if you don't have that, it's on you not Apple or the uncompensated Hackintosh devs to figure it out".
How times change, I guess.
Edit: s/plug-and-pay/plug-and-play/ Freudian slip, I guess.
if going through trouble means "doing less shit to lock their systems down", then yes.
Apple ultimately dgaf about linux.
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.
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.
In my comment I simply noted that the comments there are extremely anti-Apple yet without any solid arguments behind them, and I also noted that the whole thing is just because of an APFS flag which could be fixed from Asahi's side. The main reason I made the comment is because I am shocked at how poorly backed the arguments are.
As for Apple not helping the Linux team, why would they, or any major OEM? Apple is perfectly happy with https://github.com/apple/container
> why would they, or any major OEM?
Apple Silicon doesn't expose any obvious ACPI-equivalent power management interface. Apple could very easily document that hardware without exposing proprietary devicetree drivers, but someone internally must love watching Asahi users suffer through cpuidle. There isn't likely to be advanced power management drivers for Apple Silicon on Linux within this decade.
At the very least, I think it's fair to expect Apple to document breaking iBoot changes. They don't have to, but they feed a dog's dinner to their power users when they don't.
Amazing levels of confidence, when per Asahi's last progress report, one exists already.
> The power management architecture on this platform is incredibly complex, and there are a lot of moving parts involved in making it all work. There is Power Manager (PMGR), which is responsible for the SoC’s power domains, but there is also the Power Management Processor (PMP), which does… stuff?
> The actual low-level details of how power is managed across the SoC are quite opaque. [...] PMP will not read these reports if it is not booted, and certain power management functionality will not work. We are not sure exactly what it does with this information, but it likely involves controlling Apple Fabric power and clocking, among other things.
> There is obviously still work to be done to reach macOS levels of idle and suspend time
I still do not think that we will get advanced power management equivalent to ACPI within this decade, unless Apple starts documenting stuff. It took Asahi six years to replace cpuidle on M1, we're going to be here for a while.
People were screwed so many times by so many companies, they have been taught the hard way to behave like that: either make a lot of noise and hate in the first stage, or just agree that some functionality has been removed to milk more money etc.
However, when a company sells a device, as opposed to providing it for lease, I do not believe that it has the right to not document any feature of the device that is relevant for its usage, like it should also not have the right to impose any constraints on how the owner should use what has been bought.
Obviously, the owner of any kind of things may not use them to perform illegal acts, but that is a constraint imposed by the valid laws, not by the seller of the things.
Today, far too many companies claim to sell things, but they also attempt to control what the owner may do with them. I avoid to buy such things, but my choices are limited by those who buy them, allowing these policies to be beneficial for the sellers.
> I do not believe that it has the right to not document any feature of the device that is relevant for its usage.
This is an extremely broad requirement to place on any and all manufacturers. I agree companies shouldn't intentionally restrict what you can do with your stuff, but on the other hand, if you're trying to rebuild your lawn mower into a motorbike, you can't really be mad that the company didn't provide you with a specification the exact dimensions of the exhaust, can you?
"Concerned people are insane anti-Apple without any solid arguments, lol"
It's like they are looking at a specific application, finding that Macs are bad at it, and declaring it crap in every way, which isn't true.
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.
That's because it's Unix, not Linux.
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]
[1] https://www.osnews.com/story/141633/apples-macos-unix-certif...
> ... 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.
Anyways, "real UNIX systems must implement UUCP" is still extremely silly.
The nature of temporary waivers makes this untrue per the post you cited - The Open Group only grants them for 12 months, and the post is over a year old.
IMO, the only significant call-out is APFS case insensitivity by default, which makes the default volume a non-conforming filesystem. However, UNIX certification does not forbid you from mounting non-conforming filesystems (such as FAT32). Instead, this means the majority of software which makes certain assumptions about being used with UNIX conforming filesystems in addition to running on a UNIX conforming operating system are at risk of breaking.
Let's just say I have my doubts the author would have written a similar post if the final HP-UX release had "lied" about their certification by shipping with root login disabled by default and ulimit -c defaulting to zero.
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 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.
I don't believe that Apple has ever acknowledged the project at all, let alone promote it. Apple is neutral towards their work as far as I can tell.
How do you draw that conclusion based on their public indifference? If they acknowledged it and promoted, you could assume they are pro Asahi. But them not acknowledging it doesn't imply they aren't anti Asahi.
If they actually wanted that project to succeed and bring more diversity to Mac dev ecosystem, they'd help the project outright. Meanwhile they continue to exploit Linux for their dev purposes while still locking you into the macOS. This is their clear strategy, i.e. to make you continue to use macOS even when you prefer Linux as dev platform, just based on what they showed during WWDC. They aren't neutral.
On the other hand I doubt that's intentional. Even as an avid Apple critic I want to mention that people I trust and are more involved with Asahi, always pointed out that Asahi received the occasional little help from Apple devs where possible (surely, not with official documentation, or confidential infos).
So, I would wait until things had time to calm down and not get too invested with Apple bashing.
https://x.com/XenoKovah/status/1339914716454526979
> I purposely designed a mechanism so that M1 Macs would retain the capability to boot completely arbitrary code instead of XNU if users wanted. But you have to 1) reboot to recoveryOS with a physical power button press and 2) put in your SEP-backed credentials.
> The challenge to running arbitrary code of course, as @marcan42 noted in his crowdfunding effort to getting linux on the M1, is that the SOC is undocumented, so you still have to reuse bits of XNU and/or reverse engineer a bunch of stuff.
> As one senior architect said "the contract is that there is no contract". So that Apple can change things to suit its own needs, not others', to build the best macOS experience, which is what most customers (besides y'all who follow me) are there for.
12.1 also added support for raw image boot, which was seemingly for, and has only been relevant to, making booting Asahi Linux easier. Discussion at the time https://news.ycombinator.com/item?id=29591578 and an archive of the tweet's content below:
> Looks like Apple changed the requirements for Mach-O kernel files in 12.1, breaking our existing installation process... and they also added a raw image mode that will never break again and doesn't require Mach-Os. And people said they wouldn't help. This is intended for us.
A consumer shouldn't be restricted from installing their own OS on a device that they bought, be it a smartphone, tablet, laptop, desktop, or server.
A company the size of Apple should also be required to release proper documentation that enables the porting of operating systems to these kinds of devices.
The reverse engineering work that the Asahi team did is remarkable but so much of it is ultimately busy work that didn't need to be done if we regulated the consumer electronics market appropriately.
That is not what the industry, that pays lobby money, wants. They want to be able to control what the user runs and extract profits.
For every niche thing you wish that Apple or other third parties do only for your own enjoyment, there are hundreds of millions of other people who want different niche things. Buy the products that suit your needs and wants, and companies have incentive to make them. And if no company wants to provide a feature or function that you know a huge portion of people will want, then you have a golden opportunity to start a business providing this.
We're talking Apple publishing specs for their hardware. That's not some "niche, particular, random" feature each persons asks for. We're all asking the same thing. Same thing that IBM did and what made the PC and IT industry as we know it.
> You've been misguided into following a false religion.
You're being misguided by your patronizing attitude.
I don't believe it. Ask a random number of people or a random number of Apple customers, and less than a fraction of a percent will say that the option to install Linux on their MacBook is what they most want from Apple.
More people will probably ask for a handle, or LED flashlight, or how about built-in invoicing software? Should the EU (praised be their names) force Apple to give these customers what they want? Why would their wants be any less important than yours?
They’re 100% commodity hardware and fully locked down from any user freedom. Weirdly everyone focuses on Apple with all their might instead of gaming consoles.
It is cheaper for hardware manufacturers to only support a single operating system instead of designing a platform to be used by many. It also makes security simpler.
We must demand hardware which strongly adheres to the GNU/FSF ethos or it must be rejected society-wide (or made too expensive for the average normie to afford, effectively killing its market). Universal Machines are to free humanity, not limit or enslave us! THIS is why I don't buy Apple and hold my nose buying x86 (Qubes OS) and Google Pixels (GrapheneOS); if I could afford Raptor Engineering's TALOS II, I would own only that!
Game consoles had a higher import tax than "computers" -> allow linux, save money.
IIRC they did a similar thing with the PS2 with some janky-ass BASIC interpreter being available.
IMO it's pretty arbitrary. I wouldn't expect to run software on an appliance, even if the underlying hardware is commodity. And an appliance is something that performs a specific task (fridge, car, etc.). There are gray area cases though when an appliance does more than its basic function (smart fridge, car infotainment).
I should be able to put in a Linux DVD or memory stick and install Linux on it.
Or at the _very_ least an alternative app store.
Lifetime Xboxes sold: ~200 Million
Lifetime iPhones sold: 3 Billion
Why is it weird?
In any case, though, Apple agrees with you, and they explicitly built support for non-macOS OSes into the bootloader. This is a bug in the first developer beta of a new release.
"A foreign power could potentially deny access to the OS" sounds like a compelling argument.
This isn't incompatible with allowing users to install their own software. There just isn't an obligation on the original designers to make sure that software works. That onus is on the designers of that software.
Regulate what exactly? Bugs? That's what this was...
Today, outside of a few niche areas such as motorsport and commercial uses such as buses and coaches, nobody buys a vehicle this way. If you walked into your local Ford or Toyota and asked for a rolling chassis they would look at you as if you were insane, and rightly so. Integrating the development of the chassis and body into a single unit (both philosophically and literally [0]) has given us cars which are lighter, faster, more efficient, more featureful and safer by every measure.
We had our coachbuilding period in personal computing and it's all but over[1]. Nobody asks for the hardware and operating system to be sold separately for their washing machine, their TV, their microwave oven, PlayStation or Tesla EV. And yet for some reason some still cling to the idea that tablets and smartphones are personal computers rather than recognising them for the appliances they are.
As Steve Jobs allegedly said, design is not how something looks, design is how something works. How a feature works on a highly evolved device like an iPhone is a function of tightly coupled and carefully designed hardware and software.
Having this design process take place in different teams inside different companies, selling in different commercial models would not lead to a better outcome, it would be worse, much worse. The staggering commercial success of both iPhone and iPad is all the proof you need.
If hobbyists want to hobby, more power to them! But it's not something any government needs to regulate into existence.
[0] https://en.wikipedia.org/wiki/Vehicle_frame#Unibody
[1] Servers/Linux are the commercial vehicles in this analogy