4 ms·

Secure Boot can be disabled on Arm macs. Guess that Craig Federighi says this because Apple won't take care of drivers for other OSes. See this WWDC session: h

by my123 6y ago

Secure Boot can be disabled on Arm macs. Guess that Craig Federighi says this because Apple won't take care of drivers for other OSes. See this WWDC session: https://developer.apple.com/videos/play/wwdc2020/10686 https://developer.apple.com/videos/play/wwdc2020/10686 and this manpage: https://pastebin.ubuntu.com/p/RwcT8stYMY/ https://pastebin.ubuntu.com/p/RwcT8stYMY/

cercatrova 6y ago
While that may be true, due to custom ARM instructions that Apple uses, it might be difficult to port various other OS onto it. We'll see though.
- vlovich123 6y ago
  I would think the bigger problems are drivers & secure boot rather than just instructions. M1 is a regular ARM processor so existing backends at a minimum would work fine even if they're not fully optimized (+ I would be a bit surprised if the M1 support for LLVM isn't upstreamed).
  - cercatrova 6y ago
    Is that really true that M1 is just an ARM processor? I've heard the difficulty in emulating it is due to Apple specific things, whether they be drivers or new instructions.
    - ithkuil 6y ago
      It's an asymmetrical situation: If you have code that makes use of custom instructions, even if only sprinkled in a few places, the emulator must support them. If you have a cpu with those extra instructions that is otherwise backwards compatible, you can run code that doesn't make use of such instructions just fine (of course, you won't benefit from the functionality/performance offered by those new instructions)
    - vlovich123 6y ago
      I understood this thread to be about running Linux bare metal natively on the M1, so there's no emulation there & new instructions don't matter. Drivers & secure boot are always the biggest problem. It sounds like you can sign your own kernel & add it so in theory secure boot may not be a problem. Then the question is which driver support are missing & need implementation & how close that lines up with existing ARM device trees.
      - my123 6y ago
        An experimental Linux kernel that runs on Apple A10 devices is at: https://github.com/corellium/linux-sandcastle https://github.com/corellium/linux-sandcastle See https://arstechnica.com/gadgets/2020/03/project-sandcastle-brings-android-to-the-iphone/ https://arstechnica.com/gadgets/2020/03/project-sandcastle-b... on details about it. This work, especially as there's no exploiting security bugs required here, will benefit Linux on those Macs quite a lot.
        vlovich123 6y ago
        > This work, especially as there's no exploiting security bugs required here, will benefit Linux on those Macs quite a lot. Right, it sounds like Apple was very careful to provide an out here for enthusiasts by making it possible to sign your own kernel, something you can't do for iPhone/iPad/Watch. Seems like an astute appreciation of differences in their target market.
protoman3000 6y ago
Really curious to know how you found out about bputil. It doesn’t seem to appear in the WWDC session you linked.
- my123 6y ago
  It's more knobs over csrutil. Chose the bputil manpage as it contains more info on the underlying hardware and security model, and allows you to selectively disable only some of the security bits.

by my123 6y ago

cercatrova 6y ago

While that may be true, due to custom ARM instructions that Apple uses, it might be difficult to port various other OS onto it. We'll see though.

vlovich123 6y ago
I would think the bigger problems are drivers & secure boot rather than just instructions. M1 is a regular ARM processor so existing backends at a minimum would work fine even if they're not fully optimized (+ I would be a bit surprised if the M1 support for LLVM isn't upstreamed).
- cercatrova 6y ago
  Is that really true that M1 is just an ARM processor? I've heard the difficulty in emulating it is due to Apple specific things, whether they be drivers or new instructions.
  - ithkuil 6y ago
    It's an asymmetrical situation: If you have code that makes use of custom instructions, even if only sprinkled in a few places, the emulator must support them. If you have a cpu with those extra instructions that is otherwise backwards compatible, you can run code that doesn't make use of such instructions just fine (of course, you won't benefit from the functionality/performance offered by those new instructions)
  - vlovich123 6y ago
    I understood this thread to be about running Linux bare metal natively on the M1, so there's no emulation there & new instructions don't matter. Drivers & secure boot are always the biggest problem. It sounds like you can sign your own kernel & add it so in theory secure boot may not be a problem. Then the question is which driver support are missing & need implementation & how close that lines up with existing ARM device trees.
    - my123 6y ago
      An experimental Linux kernel that runs on Apple A10 devices is at: https://github.com/corellium/linux-sandcastle https://github.com/corellium/linux-sandcastle See https://arstechnica.com/gadgets/2020/03/project-sandcastle-brings-android-to-the-iphone/ https://arstechnica.com/gadgets/2020/03/project-sandcastle-b... on details about it. This work, especially as there's no exploiting security bugs required here, will benefit Linux on those Macs quite a lot.
      - vlovich123 6y ago
        > This work, especially as there's no exploiting security bugs required here, will benefit Linux on those Macs quite a lot. Right, it sounds like Apple was very careful to provide an out here for enthusiasts by making it possible to sign your own kernel, something you can't do for iPhone/iPad/Watch. Seems like an astute appreciation of differences in their target market.

protoman3000 6y ago

Really curious to know how you found out about bputil. It doesn’t seem to appear in the WWDC session you linked.

my123 6y ago
It's more knobs over csrutil. Chose the bputil manpage as it contains more info on the underlying hardware and security model, and allows you to selectively disable only some of the security bits.