6 ms·

Apparently there a decent chunk of the Apple Silicon files come in the form of binary files which seem to fall under the APSL. From the sounds of it, the binari

Apparently there a decent chunk of the Apple Silicon files come in the form of binary files which seem to fall under the APSL. From the sounds of it, the binaries may be quite useful for reverse engineering and putting to use in the Linux port. From Marcan (who is porting Linux to the M1) > Wait no, hold on, WTF. They do supoprt M1. Just not in source code. They freaking bundled some .a files with uncensored binaries of the parts of xnu that need to support M1. More details here: https://twitter.com/marcan42/status/1355907973776723971 https://twitter.com/marcan42/status/1355907973776723971 While the binaries aren't quite as nice as source, its a good basis for reverse engineering some of the M1 specific code needed.

marcan_42 6y ago
The 11.1 source included the blobs as .a files, ostensibly APSL licensed. The 11.2 source moved those to the KDK (this is what the article is talking about), so they are no longer APSL, and further censored the source in the actual XNU open source release. It is quite evident at this stage that this is somehow related to ARM. They must not like Apple adding nonstandard extensions to the ISA, and they want them to hide them all. The good news is we don't have to care, and the (accidentally or not) "APSL" blob release gives everyone license to reverse engineer them, since it's not under an EULA.
- ogre_codes 6y ago
  Love to know how/ why this got pushed out. If it's a rogue engineer, a mistake, or what exactly. Regardless, you can't put the cat back in the bag.
  - drvdevd 6y ago
    Sounds like Apple wants to promote or enable development on its new platform (even of 3rd party kernels), but can’t just distribute source due to some ARM licensing agreements or other legal/contractual restrictions. This is probably a middle ground through legal.
  - manwe150 6y ago
    IANAL, but I think they could retroactively claim the code in the archive was not legally their right to push under that license. That is the same principle that stops me from going further, say, and copying their APSL code into a GPL program, and then claiming the whole XNU source is now completely free and no-take-backs. So it depends on whether they owned the copyright to the original source, and also that the published bundle was authorized by Apple to provide that content. Absent timely clarification from any party, however, I think we can assume it is out in the open.
    - ogre_codes 6y ago
      They aren't/ can't use the code in any case. They can use it to see how it was done and create an alternate implementation without using any of the original code/ binaries. Worse case, they can build a model of what is done and describe that to a third party who has never had access to the code in question. Essentially forming an information firewall.
    - marcan_42 6y ago
      The code is theirs. All evidence points to this being about contractual obligations with ARM, but those would not be about copyright.
    - scruffyherder 6y ago
      All the Darwin 0.1 and 0.3 stuff has effectively been wiped.. I only got lucky with people hoarding CD’s but there is no 0.2 stuff. The amount of stuff released was shrinking by the release so did they cancel the 1.0 and 1.1 license or do they just pretend it didn’t happen? This is a 4.4BSD so there was the shadow of the AT&T vs CSRG/BSDi I’ve received no CDL...
- saagarjha 6y ago
  What makes you think that Apple needs to care what ARM thinks? All signs point to Apple having fairly strong influence on what is allowed by licensees, and obfuscating and hiding their proprietary security features is something that Apple does literally all the time…
- lukeh 6y ago
  There are some TSO-related preprocessor macros that are still there.
bad_hat_henry 6y ago
He is still working on porting Linux? I’m pretty sure it already has been done. https://twitter.com/cmwdotme/status/1355660127433535490?s=21 https://twitter.com/cmwdotme/status/1355660127433535490?s=21
- ogre_codes 6y ago
  They have linux booting on bare metal. Still to be done: - GPU drivers - Wifi/ network drivers - Power management - Getting the GUI online - Audio - Bluetooth - Webcam Extra credit: - Fingerprint scanner (This may never be possible due to Secure Enclave) - Neural Engine support - ??? other M1 extensions
  - bad_hat_henry 6y ago
    It says WiFi/Ethernet is done. It also looks like Power management is done? Getting GUI online? The pictures show a full desktop working.
    - marcan_42 6y ago
      They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution. Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it: https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 That's literally all you need to get "graphics". I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop". FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers. I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)

marcan_42 6y ago

The 11.1 source included the blobs as .a files, ostensibly APSL licensed. The 11.2 source moved those to the KDK (this is what the article is talking about), so they are no longer APSL, and further censored the source in the actual XNU open source release. It is quite evident at this stage that this is somehow related to ARM. They must not like Apple adding nonstandard extensions to the ISA, and they want them to hide them all. The good news is we don't have to care, and the (accidentally or not) "APSL" blob release gives everyone license to reverse engineer them, since it's not under an EULA.

ogre_codes 6y ago
Love to know how/ why this got pushed out. If it's a rogue engineer, a mistake, or what exactly. Regardless, you can't put the cat back in the bag.
- drvdevd 6y ago
  Sounds like Apple wants to promote or enable development on its new platform (even of 3rd party kernels), but can’t just distribute source due to some ARM licensing agreements or other legal/contractual restrictions. This is probably a middle ground through legal.
- manwe150 6y ago
  IANAL, but I think they could retroactively claim the code in the archive was not legally their right to push under that license. That is the same principle that stops me from going further, say, and copying their APSL code into a GPL program, and then claiming the whole XNU source is now completely free and no-take-backs. So it depends on whether they owned the copyright to the original source, and also that the published bundle was authorized by Apple to provide that content. Absent timely clarification from any party, however, I think we can assume it is out in the open.
  - ogre_codes 6y ago
    They aren't/ can't use the code in any case. They can use it to see how it was done and create an alternate implementation without using any of the original code/ binaries. Worse case, they can build a model of what is done and describe that to a third party who has never had access to the code in question. Essentially forming an information firewall.
  - marcan_42 6y ago
    The code is theirs. All evidence points to this being about contractual obligations with ARM, but those would not be about copyright.
  - scruffyherder 6y ago
    All the Darwin 0.1 and 0.3 stuff has effectively been wiped.. I only got lucky with people hoarding CD’s but there is no 0.2 stuff. The amount of stuff released was shrinking by the release so did they cancel the 1.0 and 1.1 license or do they just pretend it didn’t happen? This is a 4.4BSD so there was the shadow of the AT&T vs CSRG/BSDi I’ve received no CDL...
saagarjha 6y ago
What makes you think that Apple needs to care what ARM thinks? All signs point to Apple having fairly strong influence on what is allowed by licensees, and obfuscating and hiding their proprietary security features is something that Apple does literally all the time…
lukeh 6y ago
There are some TSO-related preprocessor macros that are still there.

bad_hat_henry 6y ago

He is still working on porting Linux? I’m pretty sure it already has been done. https://twitter.com/cmwdotme/status/1355660127433535490?s=21 https://twitter.com/cmwdotme/status/1355660127433535490?s=21

ogre_codes 6y ago
They have linux booting on bare metal. Still to be done: - GPU drivers - Wifi/ network drivers - Power management - Getting the GUI online - Audio - Bluetooth - Webcam Extra credit: - Fingerprint scanner (This may never be possible due to Secure Enclave) - Neural Engine support - ??? other M1 extensions
- bad_hat_henry 6y ago
  It says WiFi/Ethernet is done. It also looks like Power management is done? Getting GUI online? The pictures show a full desktop working.
  - marcan_42 6y ago
    They have a desktop running on simplefb. That is not a usable desktop (no matter what they say), with zero acceleration and all completely software rendered. There is literally no graphics or display driver. The bootloader gives you a chunk of RAM that is the screen and you write stuff to it. No multidisplay, no resolution switching, no hotplugging, no acceleration. It's like running x86 linux on efifb with no radeon/intel/nvidia drivers at all. Think vesafb for those old enough to remember those days, but even dumber - at least on that one you could pick a resolution. Our kernel has simplefb support too, literally all you need to do is write 5 lines of devicetree properties to get that to work - zero patches needed to the upstream simplefb driver. Here is the code in our bootloader that takes the Apple framebuffer information and stuffs it in the DT for Linux to use it: https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 https://github.com/AsahiLinux/m1n1/blob/main/src/kboot.c#L59 That's literally all you need to get "graphics". I was actually planning on doing exactly the demo that they did since December, with a simplefb "full Ubuntu desktop" and everything else running off of USB, for the clickbait, because it's flashy even though it's a minimal amount of work, but with a clear disclaimer that it's a tech demo and there is a lot of work left to do. It certainly brings in the news. However, it is not a "fully usable Linux desktop". FWIW: WiFi is Broadcom FullMAC (existing Linux driver) with some patches. Ethernet is a Broadcom chip over PCIe (once you have PCIe up, the driver is there). USB is DWC3 (existing Linux driver) with just an Apple PHY adaptation layer. Storage is NVMe with Apple hacks and a horrible (definitely not upstreamable) hack Corellium wrote to fake a PCIe bus because the Linux NVMe driver assumes PCIe. Please don't assume they are cranking out bespoke drivers every other day; most of their work is simple drivers and patches to existing ones. There is certainly work involved in figuring out all these Apple oddities, but these aren't new drivers. I fully intend to support the SEP in our kernel once we get that far, with Touch ID for Linux log-in/unlock and also things like storing and using SSH keys within the SEP (think built-in YubiKey). Lots of reversing to be done, but all of this is in scope for our project. Drop by our IRC if you'd like to help out :)