OpenBSD obviously doesn't have NVIDIA support, but amdgpu(4) works pretty well. I'd also prefer to use AMD's own GPU, not only because I can't use NVIDIA, but also because I don't support NVIDIA's business practice.
First of all the feature wasn't available in the initial Big Sur release and it only got available during the Betas for the first minor patch. Second of all, some Apple developer stated on Twitter that (during M1 unveil) he's finally able to show all the boot policy work they worked on the past year(s) to allow users to boot foreign OSes and without opening up holes for attackers.
Basically it boils down to: they could have just used iBoot without changing it at all to keep it as a brick like the iPhone/iPad/Watch, but instead they invested plenty of resources to allow it.
With all that work done to allow it, I'm sure there'll be plenty of people inside of Apple who'd protest if someone changes their mind and decides all this has to go away.
Kind of like all the work Sony did to allow Linux on the PS4 only to kill it later?
You don't own a mac. You can only do on it what it is profitable for Apple to let you do, today.
As much as I respect the incredible RE skills required for this task, I feel like this is shaky foundation unless an unpatchable bootrom exploit is discovered. Even then new models would be patched leaving existing users with an insecure platform that they can't replace when it breaks.
You don't really own any high-tech stuff anyway (with that interpretation). You can't boot your Intel of AMD CPU without their signed and sometimes encrypted code. You can't even initialise a single core, let alone the DRAM controllers.
Everyone likes to point at Apple, because that's easy, but it's neither new nor big nor special. There are practically three things at play:
- root-of-trust, if you have a better solution than CA-based signing, by all means, let the world know
- NDA/IP/Lawyerisms
- Apple and many others aren't selling hardware, they are trying to sell experiences or ecosystems, and that is the only reason they exist at all and also the reason a lot of the beige box hardware companies are either less visible, less profitable or both
Is it fun? No. But it's not some sort of automatic malice or 'haha you don't own things but you thought you did' all the time either.
> You can't boot your Intel of AMD CPU without their signed and sometimes encrypted code.
Except that Intel and AMD don't care what you run on your machine, they don't lose money if you don't run their software.
When you run Linux on a MAC, Apple isn't getting money from their iCloud subscriptions and from the store so they have a motive to stop you from escaping the walled garden.
If they can sell you a mac for $1500 I don't think they are very concerned that you're not spending 50 bucks a year on iCloud.
I mean, if they prevent Linux you probably won't buy a mac at all, you won't prioritise using an M1 macbook over using Linux if you're a hardcore Linux nerd.
Bottomline is that yes they are greedy, but they are not trying to stop people from installing Linux on macs just to perhaps earn some extra dollars.
Counter point: they have no problem charging $1000+ for iPhones and lock them down to only run the operating systems and apps they approve because consumers of them were largely not technical enough to understand they don't own their own devices.
Apple is motivated to do this as soon as they feel they can get away with it and keep profits as high or higher.
I’m not saying they have any moral objections to locking the macs, it just doesn’t make any financial sense. Enough people want to run windows or linux for them to make the effort to make that possible. It’s also more in the spirit of PCs to have this possibility.
For phones, basically nobody wants to run android on an iphone, so it makes no sense to make it possible.
Keep in mind that they don’t lock down iOS because they hate our freedoms, it’s because it is much harder to make it safe and secure if it’s also very open. And since the market of people wanting to run other OSs is so small, they don’t want to take the additional cost.
As to owning you device. Unless you buy real hand stitched shoes with leather soles, your shoes are most likely completely impossible to repair, they’re basically molded rubber. It’s not because Nike hates freedom or even because they want you to buy new shoes more often, it’s because it’s so much cheaper to make shoes that way. But would you argue that you “don’t own your sneakers”?
How do you know the number of people that want this, and how large is the number of 'enough', and what other numbers come in to play? (Number of incidents, number of happy users, number of systems to support, number of binaries to consider during upgrades, number of sales... and is 'enough' a percentage? An absolute number? And how high does it need to be? And to what degree does it need to align with the goals of the product teams?)
My gut feeling would say: a bunch of hackers would be happy if they can hack on their code on Apple hardware but run plain FreeBSD or Linux while doing it. But that is not something you run a multi-billion business on...
My argument is that Apple wouldn’t be losing money by allowing people to install Linux on macs, it’s not about “preventing people from using macs without paying for iCloud”.
But in general, running Windows or Linux on macs is not uncommon, it’s definitely not just for hackers.
I don’t have any numbers at all but I’m sure nobody would doubt that it is orders of magnitude more common than people wanting to run homemade OSs on iphones.
PS3, and supposedly that was because some jurisdictions treated game consoles and computers differently for import tariffs (computers being cheaper to import), but those jurisdictions changed to not having a distinction.
Agreed with the underlying point you're making though. They allow this because it aligns with their current strategic objectives, and changes to those objectives can be arbitrary and capricious, at least from the viewpoint of the consumer.
There were two versions of the PS3: The original model and a slimmed down version released after a few years.
the timeline was something like this:
- Sony released the original PS3 with Linux running under a hypervisor that locked certain things (e.g. 3D rendering and their DRM)
- Sony released the PS3 slim without Linux. They claimed they didn't have the resources to make Linux run on it. (We later figured out all that was required were a few incredibly simple kernel patches)
- geohot found a somewhat unstable hardware glitch that, with some luck and a few tries, could escalate to hypervisor mode and enable e.g. 3D rendering from Linux. Their DRM was still untouched at this point and no one really cared.
- Sony released an update for the old PS3 models to disable Linux as well citing "security concerns"
After that more people started looking into the PS3 and marcan, me and others at fail0verflow eventually figured out their security wasn't all that great. It was actually so bad that we could calculate their private keys. Then they sued us for that but that's another story.
We talked about how you could compute private keys but didn't release any keys for obvious reasons.
Essentially Sony had N different sets of keys protecting different levels of their system (e.g. one keyset for the hypervisor and another one for the kernel). What we found allowed to compute the private signing key given two public signatures.
Due to some technicality this meant that you needed another bug which allowed to extract these plaintext signatures. (The best comparison today would be that we found a universal code execution bug but you still needed to find your own info leak to defeat ASLR which we either didn't share or didn't have for all keysets).
What happened then was that geohot used this flaw we found together with a simple bug that leaked two plaintext signatures to extract one of the most important keys and published that one on his website.
Sony responded by suing him and us as well - probably because they assumed that we worked together. After a few month they reached a settlement with geohot where he promised to never hack any Sony product ever again. At the same time they simply dropped the lawsuit against marcan, me and a few other friends from fail0verflow without having ever served us.
Those months resulted in quite some stress for me and personal and legal issues for another friend.
I actually think other os got canned before the jailbreak. If I recall correctly it provided extra incentive.
They may have wanted to make it harder to jailbreak. Another argument is that they weren't profitable to sell as computers but largely become profitable via the money they made off games sold for the platform including money paid by game developers.
The same goes for any device you can buy today. We should demand more of manufacturers in general, I agree.
But you cannot expect that Apple should give you a legally enforceable contract (or whatever) pertaining to a product you haven't bought yet and they haven't even made yet.
The fact that the boot process on the M1 chip is explicitly not locked down on release is at least showing a modicum of goodwill.
Apple's outright said it's a matter of Microsoft agreeing to license Windows on ARM for consumers. Right now putting Windows on an ARM Mac is about as legal as Hackintoshing.
I don't think that's what Apple said at all–they just said the ball is in their court, which means that they want Microsoft to write Bootcamp essentially.
Yeah. Someone - cough cough Microsoft - would need to be convinced to write a Boot Camp Assistant app equivalent (okay), a Windows bootloader (okay), various device drivers for Apple Silicon hardware revisions for Windows (big ugh), graphics drivers for Apple Silicon GPUs for Windows (VERY big ugh). Microsoft will need to very motivated to distribute Windows on ARM for this to happen, even if Apple gives them access to all the info they need which is not a given by any means.
...I don't think this is going to happen, and Apple probably doesn't either.
Apple have developed Bootcamp and provided drivers so far for Intel Mac. But shipping Bootcamp for Windows ARM would be an EULA violation until Microsoft loosen theirs conditions. Changing this is literally step 1.
Wether Apple would develop Bootcamp for ARM or not is purely theoretical discourse until then.
The only driver Apples needed to develop for Windows are Mac specifics though, like the stuff that was managed by the T1. Not trivial, but not the end of the world to have to make. Things like wifi drivers and especially the graphics drivers are just the chip vendor's standard preexisting Windows drivers.
Apple is now the vendor of at least the GPU. I don't think they're going to write a Windows driver for that - the incentives are just not there.
What you were possibly remembering was that Windows on ARM when it was first introduced only supported emulating x86 apps. Although x64 emulation is currently in preview.
That would make a lot of sense. Windows is in a tight spot right now because OEMs have lagged on ARM. Apple could offer MS a way out of that, while at the same time giving people one more reason to spend money on a Mac.
There is a significant number of people working at Microsoft who use Windows on a Mac as it's generally nice (and expensive) hardware. I'm sure they'd be thrilled to see Bootcamp operational on ARM Macs.
Right, if MS is serious about Windows on ARM, they should support the Mac as a show case and also to allow all future Mac buyers the chance to run Windows. Of course, Apple can't announce much until Microsoft makes an announcement about Windows on AS Macs.
Is MS not busy looking at doing their own ARM silicon for future Windows powered Surface devices after release of M1 and the failure Qualcomm with the Snapdragon 8cx (we just use ARM reference designs) ???.
They do have the chops for it since they have done Xbox and Hololens and various other devices in-house.
Maybe they are already developing their own "MS1" in secret ?
But even if they are, it would make sense to release Windows 10 for the M1 and getting Win-developers to start porting their applications to ARM, so they could leap-frog Apple on ARM if they manage to build a 'better' ARM SoC
Or they could take significant market share away from Windows, possibly permanently, by offering increasingly more performant machines. Seems like a better move to me.
Linus Tech Tips actually just released a video a couple of hours ago where they compared the Surface Pro X SQ2 with the M1 MacBook Air. It was not pretty.
So basically, the M1 Macbook Air is two to three times faster than the SQ2, including comparing ARM Windows on the SQ2 against ARM Windows in a VM on the M1 Air.
Relatedly, I wrote this on Twitter a few weeks ago:
cargo build of sccache on a Lenovo Yoga C630 (Snapdragon 850) in WSL: 4 minutes 55 seconds. On a Macbook Air M1: 55 seconds
WSL 1 or 2? WSL 1 has very slow disk access, so compiling can be pretty slow. I.e. I would expect WSL to be slower for disk reasons even it was running on an M1.
He’s off on the strategic focus of Apple (where he says that the M1 benefit because Apple is taking a mobile OS and adapting it for the desktop vs Microsoft is taking a desktop OS and adapting it for mobile architectures. The truth of the matter is that Apple has been consistently making CPUs for about a decade that blow away the competition on compute per watt. Like 2-3 years before the industry catches up to where Apple was. They’re just bringing that same power to laptops/PCs as they’ve saturated what that buys them on mobile (not fully but it’s not a big enough sales driver as mobile sales growth has slowed). That’s why you see AirPods and M1 - “where else can we deploy our perf per watt and vertical integration advantage”.
As for “why are there so few ARM versions of apps”, that’s purely the vertical integration piece again. Apple makes it very clear the old tech line is dead so developers have a clear thing to explain to their management. Microsoft tries to keep everyone happy which means devs are like “I’ll wait until this actually has industry buy in” which then Microsoft uses as “well there’s no interest here and maybe the tech won’t work out/vendors won’t materialize” and “we can’t ask our customers to pay this transition cost”.
Is there any point of running windows outside of intel processors? I'm aware they have an ARM offering but it's not clear what the "killer apps" of the OS/arch pair are.
I'd think linux/BSD drivers would be the concern here!
Fair enough, but since it actually uses git repositories as the storage format it uses the most interesting part of git, so my point stands about everything in between the repo and the user.
Looking at the man page, it also seems like you won't be able to share work trees between git and got. If you want to use both to operate on a repository you need a separate checkout for each tool.
OpenBSD does not run on the rPi because there are only a handful developers taking care of the arm subtree, and none of them have time for it or are simply not interested. Heck, their whole arm subtree has been rotting and needs some major overhaul.
The main components of the new rPi are rather simple to get to work, so it's not a technical issue. The only real crapware inside is the usb controller.
I bet if someone supplied a diff they'd gladly take it. Also, I wonder why this rather old post is up here.
Actually if you read the comments from the developers in that thread they won't support it until there is documentation on the firmware "blobs" you need to have in order to even boot.
I agree it is a fuzzy line but one which I happen to agree with.
There is a probably a thesis to be had for the first person to build a provably trusted system using untrusted base hardware. I am not even sure how you would start such a project.
It is a mischaracterization to say they have issues with the firmware, they clearly say they don't have the same objections to firmware running on the peripherals themselves.
The issue here is that the rPI requires driver code running inside OpenBSD that is a closed source blob.
The main blobs are being run on the GPU, as bootloaders, even before the actual operating system is loaded. OpenBSD does not need to run _any_ blob itself.
There used to be a 3d graphics driver blob, but afaik that got open sourced. Also, if you don't do 3d, you wouldn't even need it.
So, to summarize, if somebody makes a port that doesn't use a blob, all is good. The question seems to be not so much if the blob runs before or after OpenBSD, but whether we would need to distribute it. If it's in the ROM, then this isn't even a question. But if it's something we are expected to write to the flash drive, that's a potential problem. Anyway, the question isn't very interesting given that the magic porting elves haven't yet gifted us with an OpenBSD RPi port.
I don't know exactly what the situation is. Don't care. I have a BeagleboneBlack if I wanted to watch the paint dry doing a build. :)
What's OpenBSD's policy on when something needs to be included?
The rPi boot process requires several files to be on a FAT partition on an sd-card: bootcode.bin, fixup.dat, start.elf, config.txt and the OS kernel; the first 3 of which are blobs.
Would those blobs need to be included, or would OpenBSD be fine saying "use your existing boot card, just drop in our kernel", or "go grab these files from https://github.com/raspberrypi/firmware/tree/master/boot when formatting the sd-card."?
The same applies to the GPU. The rPi does not have an IOMMU, but most platforms OpenBSD supports do not have one either.
That said, based on other discussion here it seems this whole thread is a red-herring and there is no problem with the blobs, it's just that noone has written support for it.
If OpenBSD delivers the blob as part of their OS, they take moral responsibility for it (which, for good reasons, they don't want to take). On the other hand, you don't have to deliver a blob to support, say, a hard disk.
I agree 100% with the stance of not distributing blobs.
But you can put it on the user to provide it. A lot of linux distros have gone this route, if you want to boot debian on RPi you either need to create the FAT partition and put the blobs there yourself, or fetch a third-party image which includes them.
That's the mentality difference between mainstream GNU/Linux distributions (though Richard Stallman considers them as unethical and only endorses 100% free software distributions, such as Trisquel GNU/Linux (cf. [1])) and OpenBSD (for the OpenBSD mentality cf. [2]).
To my understanding, no distribution of a binary blob would be necessary. It is already flashed onto the raspberry pi. The original drivers are open source but not free, but it would be easy to at least get vga working.
My knowledge is based on the rPi1, but cursory investigation suggests that this is also true on the rPi2:
There are several blobs that are necessary to be on the sd-card for boot: bootcode.bin, fixup.dat, and start.elf. Any bootable sd-card image for the Pi has them.
What's kind of interesting is that most of what start.elf is is actually an entire OS (ThreadX, I believe), that is running on the VC4 GPU in parallel to the OS on the ARM CPU; and that most of the Linux GPU drivers for it are just shims that send messages saying "hey, ThreadX, would you mind doing this for me?"
- the VC4 starts up and a ROM starts executing
- the ROM loads bootcode.bin into the SRAM
- bootcode.bin sets up the DRAM and loads the start.elf and fixup.dat
- the start.elf sets up the ARM core and loads the Linux kernel
ARM code only starts executing at the last stage.
The only bit that's actually necessary on the SD card is the bootcode.bin --- everything else is under the control of whatever's in there.
And the bootloader had been reverse engineered (quite accurately, btw., although all the ISA mnemonics are totally made up). It should be possible now to rebuild it from assembly source.
I did read them. Now and a few months back. Janne raises concerns about running a blob on the CPU (which does not happen), while Stuart explains the boot stages correctly in detail and compares it to very similar issues on newer x86 technology.
Yes, but that's not relevant in this context, which is about OpenBSD trusting binary blobs ("a provably trusted system using untrusted base hardware").
> Actually if you read the comments from the developers in that thread they won't support it until there is documentation on the firmware "blobs" you need to have in order to even boot.
How exactly is that different to an undocumented or—forbid it—an unflashable BIOS? Don't even get me started on EFI...
Aside from coreboot, I don't really see anybody drawing the ideological-line-in-the-sand there when it comes to running their PC.
Well perhaps a better example might be System Management Mode on Intel CPUs, which easily allows for undetectable backdoors with constant access to the same physical memory as anything else running on the CPU.
That is true. OpenBSD/Theo refuses to take part in embargos, which means they don't get a heads up. Don't have a citation right now, but Theo said that publicly when Hardbleed or so happened.
The funny thing is that even though they have OpenCVS in their source tree, they do not use it. It never took off and probably had too many bugs and issues.
Instead they are and have been using GNU CVS instead.
OpenCVS was linked to the normal build for a while but has been removed from it four years ago.
