Announcement

Collapse
No announcement yet.

Asahi Linux Update Brings Experimental Apple M2 Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Developer12 View Post
    Instead they spent time and effort developing a multiboot system that explicitly allows dual-booting 3rd party unsigned OSs.
    Really? Not blocking other OSs from booting is less work not more.

    Originally posted by Developer12 View Post
    Yeah, they probably want to deploy M1 chips in the linux server space given their perf-per-watt rating
    Yeah, probably not. Perf/W is useless in the server space if you lack I/O and RAM.
    Last edited by Anux; 18 July 2022, 08:41 AM.

    Comment


    • #12
      Originally posted by Anux View Post
      Really? Not blocking other OSs from booting is less work not more.
      Actually no. The M1 is a carbon-copy of their latest cellphone chip. Implementing anything *other* than the existing locked-down boot process was work.

      Even if you wanted some magical completely unlocked boot process, they'd *still* have to put work into specifying and implementing it. There's a lot of shit that needs to be passed to an OS through the device tree in order to make things work. It's not just "load image and jump to address."

      And, what they've implemented is actually *far* more generous than that. Like it or not, a lot of people aren't going to want to sodomize their entire $3000 machine to run linux, leaving it unable to officially boot macOS ever again. The dual-boot apple implemented allows you to boot linux and macOS side-by-side, while giving apple confidence that macOS will remain untampered-with. Thus, you can do whatever the hell you want on the linux side, but still go back to macOS on monday morning when you need more than a beta installation of linux to get your work done.

      Comment


      • #13
        Originally posted by Anux View Post
        Yeah, probably not. Perf/W is useless in the server space if you lack I/O and RAM.
        Yeah, let's chuck a laptop chip directly into a server. /s

        Adding I/O and ram to a future version of the chip is par for the course if they go that route. You don't put AMD mobile processors into EPIC servers.

        What matters is if there's linux support for the architecture of the SoC, which is what Asahi are developing. Support for the boot process, support for the DART, the PCIe controllers, the various mailboxed sub-processors, etc. It's a big part of the reason moving from the M1 to the M2 only took a few days. The big parts of the puzzle were already in place. It would be stupid for apple to release a server-class system without linux support for their chips in reasonably good shape, to minimize the time spent by distros to catch up on the porting.

        Comment


        • #14
          Originally posted by Setif View Post
          As I said it before in this forums, They are wasting their times.
          Considering that Apple prefer to not fellow standards (just to sell overpriced computer parts and accessories) this project will end up like nouveau or worse.
          They should spend their knowledge, skills and times on improving Linux support for other Hardware the fellow standards.
          Just because you repeat it over and over it won't turn into less of a bullcr@p.

          Comment


          • #15
            Originally posted by Developer12 View Post
            Adding I/O and ram to a future version of the chip is par for the course if they go that route.
            And they can do that without increasing the power consumption? Then why even cut it out on the mobile chip? Also 8 cores in a server is the next limit and no they can't just put more cores in. You need an interconnect that is capable of more cores and this probably needs more power to.

            Originally posted by Developer12 View Post
            Even if you wanted some magical completely unlocked boot process, they'd *still* have to put work into specifying and implementing it. There's a lot of shit that needs to be passed to an OS through the device tree in order to make things work. It's not just "load image and jump to address."
            But the device tree and probably ACPI tables are also needed by MacOS and therefore should already exist.

            The dual-boot apple implemented allows you to boot linux and macOS side-by-side, while giving apple confidence that macOS will remain untampered-with. Thus, you can do whatever the hell you want on the linux side, but still go back to macOS on monday morning when you need more than a beta installation of linux to get your work done.
            Thats what every open source boot loader does since ages and UEFI nowadays. And if the MacOS is not completly encryptet I highly doub't that "untampered"-statement.

            Comment


            • #16
              Originally posted by Anux View Post
              And they can do that without increasing the power consumption? Then why even cut it out on the mobile chip? Also 8 cores in a server is the next limit and no they can't just put more cores in. You need an interconnect that is capable of more cores and this probably needs more power to.
              Gee, what a revelation. Mobile chips need to be smaller and laptops don't need as much performance as a server. Guess you can't use mobile chips as server chips.

              They can put in as many cores as they want when they redo the floorplan of the chip. They already have a fast enough fabric. It'd be indeed difficult to find a RAM interface as wide as the one they currently have (it already outperforms server ram) but I'm sure they could put some more ram chips on an interposer or something. Maybe borrow IBM's OMI interconnect.

              Originally posted by Anux View Post
              But the device tree and probably ACPI tables are also needed by MacOS and therefore should already exist.
              ACPI? What architecture do you think this is? x86? People are way too pampered by PC BIOSs.

              How do you think the macOS device tree gets to the OS? Where do you think the firmware images are stored? How do you think the kernel image is loaded?
              Through the iphone/ipad's secure boot flow. It would be much easier to rip it all out and rewrite it, which is what apple did.

              Originally posted by Anux View Post
              Thats what every open source boot loader does since ages and UEFI nowadays. And if the MacOS is not completly encryptet I highly doub't that "untampered"-statement.
              Apple's boot processes (all of them) enforce signature checking at every stage, all the way to their kernel. The partition your data is on is also encrypted. This provides a series of security assurances, eg. that nobody can get access to your data if your laptop/phone is stolen because only signed code can run and unlock the storage, and signed code will require a password.

              You seem to know jack shit about how boot processes actually work, much less how the boot process on the M1 does. Did you know your nice open-source grub bootloader is vetted and signed by microsoft? That's how grub can boot on a secure-boot system, and it then implements not only all the services required to boot linux but windows's EFI bootloader as well.

              If you wanted to strip everything out and have a free for all, A) you loose all assurances that your macOS data is safe (and apple looses the ability to assure themselves and others that stuff isn't tampered with) and B) if you wanted to boot macOS from your special multi-boot bootloader you'd need to do the work of implementing all the services macOS needs. Ick.

              In the end, this has worked out best for everyone. Apple's signed code asks what you want to boot and boots it, with full assurances to macOS, or just jumps into whatever bootloader linux/BSD needs (m1n1).

              Comment


              • #17
                Originally posted by Developer12 View Post
                Gee, what a revelation. Mobile chips need to be smaller and laptops don't need as much performance as a server. Guess you can't use mobile chips as server chips.
                Just a reminder, you were the one sugessting that Apple plans to put the M1 in a server because its super power efficient. By the way, do you have any link that you are basing your theories on or is it all in your head?

                They can put in as many cores as they want when they redo the floorplan of the chip.
                So they need to develop a new serverchip and leverage some design IPs from the M1. That sounds a lot more difficult than just putting in the M1 chip and is what every big ARM server chip dev already does.

                Apple's boot processes (all of them) enforce signature checking at every stage, all the way to their kernel. The partition your data is on is also encrypted. This provides a series of security assurances, eg. that nobody can get access to your data if your laptop/phone is stolen because only signed code can run and unlock the storage, and signed code will require a password.
                So how is this different from any other os with secure boot and encryption?
                Did you know your nice open-source grub bootloader
                Im not the developer of grub, its not mine.
                is vetted and signed by microsoft?
                Everyone here knows this, it was a big thing back when it was introduced. We just had another article about it here on phoronix.

                If you wanted to strip everything out and have a free for all, A) you loose all assurances that your macOS data is safe (and apple looses the ability to assure themselves and others that stuff isn't tampered with)
                That must be really bad design by apple, because UEFI can do that without loosing this assurance.

                Apple's signed code asks what you want to boot and boots it, with full assurances to macOS, or just jumps into whatever bootloader linux/BSD needs (m1n1).
                So the "whatever system" can get tempered any time? Thats hardly a good solution and looks more like Apple caring only for themselfes. Certainly not for servers that require trusted safety.

                Comment


                • #18
                  I hope Asahi Linux works on audio, video, power management, and usb before gpu.

                  Comment


                  • #19
                    Originally posted by Anux View Post
                    Just a reminder, you were the one sugessting that Apple plans to put the M1 in a server because its super power efficient. By the way, do you have any link that you are basing your theories on or is it all in your head?
                    So they need to develop a new serverchip and leverage some design IPs from the M1. That sounds a lot more difficult than just putting in the M1 chip and is what every big ARM server chip dev already does.
                    In fact if you actually bothered to read anything, you'd notice I said you would be stupid to put an AMD mobile processor in an EPIC server. The M1 has the highest perf per watt of any chip on earth, combined with a raw performance that rivals a good portion of desktop chips. It's a no-brainer for hyperscalars whose main expense is the electricity they consume to run the loads that they host.

                    Originally posted by Anux View Post
                    So how is this different from any other os with secure boot and encryption?
                    Im not the developer of grub, its not mine.
                    Everyone here knows this, it was a big thing back when it was introduced. We just had another article about it here on phoronix.
                    That must be really bad design by apple, because UEFI can do that without loosing this assurance.
                    So the "whatever system" can get tempered any time? Thats hardly a good solution and looks more like Apple caring only for themselfes. Certainly not for servers that require trusted safety.
                    Wow, you must be completely illiterate. You're having to read my comments one line at a time and can't put the big picture together.

                    It's very simple. Right now linux (or any unsigned code you want) can get loaded by apple's signed boot process, but they don't get access to the macOS partition's decryption key. No unsigned code does. It's not that hard to comprehend but somehow you just can't seem to find the brain cells to rub together to fathom it.

                    This is a complete rewrite from the boot process their phones used, which didn't allow any unsigned code to run at all. They could well have rewritten the M1's boot code to just run any old code, but then they loose the ability to provide security guarantees to anyone running macOS, whether or not they choose linux. Indeed "hardly a solution," as you barely managed to type between spelling errors. ("That's" and "themselves")

                    What apple did is really a case of have-your-cake-and-eat-it-too, because macOS gets security and linux enthusiasts get to run whatever they want to. Everyone's happy, except you apparently, whose brain is too small to comprehend more than one sentence at a time and so remain a sour ignorant of all of this.
                    Last edited by Developer12; 18 July 2022, 12:12 PM.

                    Comment


                    • #20
                      Originally posted by Developer12 View Post

                      Apple doesn't choose to make it harder. In fact apple chose to make this possible at all.

                      The iphone/ipad has a secure boot implementation that doesn't allow 3rd party OSs. Apple could have left that in place when they turned their latest mobile chip into the M1, but they didn't. Instead they spent time and effort developing a multiboot system that explicitly allows dual-booting 3rd party unsigned OSs.

                      Not to mention various bugs that only affect linux which apple have provided fixes for.
                      Credit where it's due, big BIG kudos to Apple for doing all of this.

                      Comment

                      Working...
                      X