7 ms·

Debian CD Image for AArch64 Windows Laptops

93 points by my123 6y ago

IntelMiner 6y ago
I didn't know one could run Linux on ARM64/AArch64 Windows laptops. I assumed they were "Windows Only" at a firmware level (Secure Boot forced on without any ability to opt-out or some form of signed MS only bootloader support) Between this and Marcan42 on Twitter working on Linux for M1 Macs, I'm hopeful that ARM64 Linux devices will slowly start to creep in further
- gsnedders 6y ago
  The MS requirements for Windows require secure-boot enabled by default and only with the MS key. It is optional whether OEMs allow secure-boot to be disabled and/or set to a mode where other signing keys can be added.
  - my123 6y ago
    In practice, on both x86_64 and arm64, no OEM including Microsoft themselves took the option to have always-on Secure Boot. (32-bit Arm was another story, but that era is long since dead) EDIT: think that this was worded badly, modified it.
    - xenocratus 6y ago
      I see a bunch of recent tutorials when searching for how to do this, e.g. for Acer Windows 10 laptops: https://medium.com/@acerrepaircenter/how-to-enable-or-disable-secure-boot-on-acer-laptop-c336593f2a26 https://medium.com/@acerrepaircenter/how-to-enable-or-disabl... Microsoft also seems quite positive about the option being there: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/disabling-secure-boot https://docs.microsoft.com/en-us/windows-hardware/manufactur... Edit: fair enough, sounds about right!
- sdflhasjd 6y ago
  Because Windows on Arm requires UEFI, it's much the same as installing Linux on an x86 box.
  - selfhoster11 6y ago
    There have been discussions that ARM based machines will have UEFI forced to enabled Secure Boot with a key that doesn't let Linux bootloaders run, so this would not be the same. x86 laptops and PCs generally allow replacing the boot key, or disabling Secure Boot altogether.
    - als0 6y ago
      You're thinking of 32-bit ARM machines. The 64-bit ARM software story is very different and I have yet to find an arm64 laptop that can't boot a different OS.
- mhh__ 6y ago
  Someone will almost definitely get Linux running on the Mac, but only because of talented people working on it for free (which is both a shame and slightly concerning given how some people seem to be completely suckered in by Apple)
  - freehunter 6y ago
    >only because of talented people working on it for free That’s basically the definition of Linux. That’s not Apple’s fault.
    - londons_explore 6y ago
      > That’s basically the definition of Linux. A common misconception. Something like 90+% of Linux commits come from people whose job is writing that code.
      - freehunter 6y ago
        In which case the people getting Linux running on an M1 likely aren't working for free. Either way it's not a very good criticism.
- PragmaticPulp 6y ago
  When secure boot started to go mainstream there was a lot of FUD that it was really just a mechanism to lock out alternative OSes. The reality is that hardware manufactures do not care what OS you run, as long as it doesn’t result in costly hardware returns or endless support calls. This is why hardware typically has options to disable OS-specific. secure boot, but it requires some technical steps that average users won’t accidentally stumble upon. The M1 macs were never locked down, either. Apple has said that Microsoft can make Windows builds for them if they’d like. Linux on M1 macs is only a matter of time. Secure boot is a net win for everyone. Having an option to disable it lets the 0.01% of people who want to run Linux use the hardware too.
  - officeplant 6y ago
    From what I've been made to understand by friends at Apple all they have to do is figure out iBoot. They suspect we'll have linux on M1 macs within the next 6 months.
  - ryukafalz 6y ago
    >When secure boot started to go mainstream there was a lot of FUD that it was really just a mechanism to lock out alternative OSes. It wasn't just FUD. Microsoft has changed their tune on this over the years, but it used to be that their certification requirements mandated that users could not disable secure boot on ARM devices: https://arstechnica.com/information-technology/2012/01/microsoft-mandating-secure-boot-on-arm-making-linux-installs-difficult/ https://arstechnica.com/information-technology/2012/01/micro... If that were still their policy today, it would make projects like this nearly impossible.
  - vetinari 6y ago
    Except it was not FUD: see WinRT machines, which used Secure Boot and didn't allow neither MOK enrollment nor disabling Secure Boot.
sdflhasjd 6y ago
Funny how we still call it a CD image, are there actually any AArch64 Windows laptops with a CD drive? Can you even boot from an external CD drive on such laptops?
- zinekeller 6y ago
  I'm pretty sure that even x86 UEFI cannot boot from CDs/DVDs (unless they are in BIOS emulation mode). This is the reason why physical retail Windows 10 images are in a read-only USB. Update: some enterprise UEFI setups do boot from DVDs but the ISO should be a hybrid type (aka must have EFI-style partitions).
  - roblabla 6y ago
    UEFI supports bootable DVDs, although they use an extension of El Torrito. See section 13.3.2.1 of the UEFI Specification, Version 2.8. > To boot from a CD-ROM or DVD-ROM in the boot services environment, an EFI System partition is stored in a “no emulation” mode as defined by the “El Torito” specification. This was chosen specifically to allow polyglot ISO files that can both be booted bh UEFI and legacy BIOS. The implementation of tools to create such polyglot files are, to say the least, interesting. The tools effectively generate both a FAT and ISO partition, each having its own file information table, but sharing the actual file contents.
    - xmodem 6y ago
      This sounds fascinating and horrific. Where can I learn more?
      - deleted 6y ago
        [deleted]
      - pabs3 6y ago
        https://wiki.syslinux.org/wiki/index.php?title=Isohybrid https://wiki.syslinux.org/wiki/index.php?title=Isohybrid https://repo.or.cz/syslinux.git/blob/HEAD:/utils/isohybrid.c https://repo.or.cz/syslinux.git/blob/HEAD:/utils/isohybrid.c
CyberRabbi 6y ago
Would love a more technical explanation as to why shell.efi is able to modify efivars yet the kernel unable to.
- jsmith45 6y ago
  Agreed. The claim is "The reason behind it is that EFI variables are stored on UFS, while firmware and OS cannot share the UFS device." Ok, but why can't it use the EFI runtime services to write to the efi vars, like Windows' bcdedit does? After all, bypassing the firmware to write the vars should actually be riskier, as to my knowledge UEFI does not mandate any specific format for them in NVRAM, so a vendor very much could use a custom format if they wanted, even though almost everybody just uses a modified version of the reference implementation.
  - CyberRabbi 6y ago
    I think that probably answers my question. There is a raw memory space for efivars that is accessible by the kernel but might also be under control of lower-level runtime services. If that is truly the case then I agree with you, the kernel should default to using the efi runtime to modify the efivars.
  - my123 6y ago
    On Windows, Qualcomm uses the SCM driver to hook the Get/SetVariable implementation and replace it with their own. The UEFI standard SetVariable implementation is nonfunctional and the GetVariable one is at the same state since ExitBootServices. This is due to the fact that the firmware and the OS cannot control the storage device at the same time. The issue isn't seen on most x86 PCs since those use a separate SPI flash chip for the UEFI.
wila 6y ago
Personally I had a good experience with the original debian arm image: https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/ https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/

93 points by my123 6y ago

I didn't know one could run Linux on ARM64/AArch64 Windows laptops. I assumed they were "Windows Only" at a firmware level (Secure Boot forced on without any ability to opt-out or some form of signed MS only bootloader support) Between this and Marcan42 on Twitter working on Linux for M1 Macs, I'm hopeful that ARM64 Linux devices will slowly start to creep in further

gsnedders 6y ago
The MS requirements for Windows require secure-boot enabled by default and only with the MS key. It is optional whether OEMs allow secure-boot to be disabled and/or set to a mode where other signing keys can be added.
- my123 6y ago
  In practice, on both x86_64 and arm64, no OEM including Microsoft themselves took the option to have always-on Secure Boot. (32-bit Arm was another story, but that era is long since dead) EDIT: think that this was worded badly, modified it.
  - xenocratus 6y ago
    I see a bunch of recent tutorials when searching for how to do this, e.g. for Acer Windows 10 laptops: https://medium.com/@acerrepaircenter/how-to-enable-or-disable-secure-boot-on-acer-laptop-c336593f2a26 https://medium.com/@acerrepaircenter/how-to-enable-or-disabl... Microsoft also seems quite positive about the option being there: https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/disabling-secure-boot https://docs.microsoft.com/en-us/windows-hardware/manufactur... Edit: fair enough, sounds about right!
sdflhasjd 6y ago
Because Windows on Arm requires UEFI, it's much the same as installing Linux on an x86 box.
- selfhoster11 6y ago
  There have been discussions that ARM based machines will have UEFI forced to enabled Secure Boot with a key that doesn't let Linux bootloaders run, so this would not be the same. x86 laptops and PCs generally allow replacing the boot key, or disabling Secure Boot altogether.
  - als0 6y ago
    You're thinking of 32-bit ARM machines. The 64-bit ARM software story is very different and I have yet to find an arm64 laptop that can't boot a different OS.
mhh__ 6y ago
Someone will almost definitely get Linux running on the Mac, but only because of talented people working on it for free (which is both a shame and slightly concerning given how some people seem to be completely suckered in by Apple)
- freehunter 6y ago
  >only because of talented people working on it for free That’s basically the definition of Linux. That’s not Apple’s fault.
  - londons_explore 6y ago
    > That’s basically the definition of Linux. A common misconception. Something like 90+% of Linux commits come from people whose job is writing that code.
    - freehunter 6y ago
      In which case the people getting Linux running on an M1 likely aren't working for free. Either way it's not a very good criticism.
PragmaticPulp 6y ago
When secure boot started to go mainstream there was a lot of FUD that it was really just a mechanism to lock out alternative OSes. The reality is that hardware manufactures do not care what OS you run, as long as it doesn’t result in costly hardware returns or endless support calls. This is why hardware typically has options to disable OS-specific. secure boot, but it requires some technical steps that average users won’t accidentally stumble upon. The M1 macs were never locked down, either. Apple has said that Microsoft can make Windows builds for them if they’d like. Linux on M1 macs is only a matter of time. Secure boot is a net win for everyone. Having an option to disable it lets the 0.01% of people who want to run Linux use the hardware too.
- officeplant 6y ago
  From what I've been made to understand by friends at Apple all they have to do is figure out iBoot. They suspect we'll have linux on M1 macs within the next 6 months.
- ryukafalz 6y ago
  >When secure boot started to go mainstream there was a lot of FUD that it was really just a mechanism to lock out alternative OSes. It wasn't just FUD. Microsoft has changed their tune on this over the years, but it used to be that their certification requirements mandated that users could not disable secure boot on ARM devices: https://arstechnica.com/information-technology/2012/01/microsoft-mandating-secure-boot-on-arm-making-linux-installs-difficult/ https://arstechnica.com/information-technology/2012/01/micro... If that were still their policy today, it would make projects like this nearly impossible.
- vetinari 6y ago
  Except it was not FUD: see WinRT machines, which used Secure Boot and didn't allow neither MOK enrollment nor disabling Secure Boot.

sdflhasjd 6y ago

Funny how we still call it a CD image, are there actually any AArch64 Windows laptops with a CD drive? Can you even boot from an external CD drive on such laptops?

zinekeller 6y ago
I'm pretty sure that even x86 UEFI cannot boot from CDs/DVDs (unless they are in BIOS emulation mode). This is the reason why physical retail Windows 10 images are in a read-only USB. Update: some enterprise UEFI setups do boot from DVDs but the ISO should be a hybrid type (aka must have EFI-style partitions).
- roblabla 6y ago
  UEFI supports bootable DVDs, although they use an extension of El Torrito. See section 13.3.2.1 of the UEFI Specification, Version 2.8. > To boot from a CD-ROM or DVD-ROM in the boot services environment, an EFI System partition is stored in a “no emulation” mode as defined by the “El Torito” specification. This was chosen specifically to allow polyglot ISO files that can both be booted bh UEFI and legacy BIOS. The implementation of tools to create such polyglot files are, to say the least, interesting. The tools effectively generate both a FAT and ISO partition, each having its own file information table, but sharing the actual file contents.
  - xmodem 6y ago
    This sounds fascinating and horrific. Where can I learn more?
    - deleted 6y ago
      [deleted]
    - pabs3 6y ago
      https://wiki.syslinux.org/wiki/index.php?title=Isohybrid https://wiki.syslinux.org/wiki/index.php?title=Isohybrid https://repo.or.cz/syslinux.git/blob/HEAD:/utils/isohybrid.c https://repo.or.cz/syslinux.git/blob/HEAD:/utils/isohybrid.c

CyberRabbi 6y ago

Would love a more technical explanation as to why shell.efi is able to modify efivars yet the kernel unable to.

jsmith45 6y ago
Agreed. The claim is "The reason behind it is that EFI variables are stored on UFS, while firmware and OS cannot share the UFS device." Ok, but why can't it use the EFI runtime services to write to the efi vars, like Windows' bcdedit does? After all, bypassing the firmware to write the vars should actually be riskier, as to my knowledge UEFI does not mandate any specific format for them in NVRAM, so a vendor very much could use a custom format if they wanted, even though almost everybody just uses a modified version of the reference implementation.
- CyberRabbi 6y ago
  I think that probably answers my question. There is a raw memory space for efivars that is accessible by the kernel but might also be under control of lower-level runtime services. If that is truly the case then I agree with you, the kernel should default to using the efi runtime to modify the efivars.
- my123 6y ago
  On Windows, Qualcomm uses the SCM driver to hook the Get/SetVariable implementation and replace it with their own. The UEFI standard SetVariable implementation is nonfunctional and the GetVariable one is at the same state since ExitBootServices. This is due to the fact that the firmware and the OS cannot control the storage device at the same time. The issue isn't seen on most x86 PCs since those use a separate SPI flash chip for the UEFI.

wila 6y ago

Personally I had a good experience with the original debian arm image: https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/ https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/