marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
klltkr has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<marcan>
need to figure out a VESA arm for it though
GreatGodvin[m] has joined #asahi
GreatGod1 has joined #asahi
GreatGodvin has quit [Ping timeout: 480 seconds]
<_jannau_>
has it any hardware which is not in the mac mini or laptop? ignoring details like the higher camera resolution. I assume the 2 USB3 ports are still driven by dwc3/pcie and are usb-c since usb-a ports would have protuded through the display
GreatGodvin[m] has quit [Ping timeout: 480 seconds]
<marcan>
we'll see I guess
GreatGod1 has quit []
<marcan>
if nothing else the display will be one more variant to test
<j_ey>
and who can turn down another m1?
<marcan>
I mean I'm making a point of being able to test all the major HW configs
<marcan>
plus there's a good chance once this all works it'll become one of my primary machines (though more likely by then a 27" M2 model will be out)
GreatGodvin has joined #asahi
<_jannau_>
being able to test every configuration is good. I was wondering if there was anything extra to support
<_jannau_>
does adt.py print any sensitive information? if not it would be helpful to have the ADT for each model in the wiki
<JTL>
marcan: I have the AmazonBasics wall mounted VESA arm, but I don't know how easy it is for you to get
<JTL>
if the VESA mount for the iMac is 100x100, it *should* work, weight permitting
<arnd>
I don't see anything surprising in there, but they don't have the corresponding mac mini teardown for comparison
kettenis_ has joined #asahi
kettenis has quit [Ping timeout: 480 seconds]
<_jannau_>
USB3 ports are using ASM3142 and a cypress usb-pd controller
bps has quit [Remote host closed the connection]
bradfier has quit [Quit: Leaving...]
bradfier has joined #asahi
<arnd>
what do the other ones use? I guess the difference is that the mini has two type-A ports, while the imac has additional Type-C ports next to the two thunderbolt ports.
<_jannau_>
the mac mini uses dwc3 for the usb-a ports
GreatGodvin has quit [Quit: WeeChat 3.1]
<arnd>
I'm confused now, I thought dwc3 was driving the type-C ports, isn't that how you get the endpoint mode on type-c?
<sven>
yeah, dwc3 is usb-c and pcie/xhci is usb-a
aleasto has joined #asahi
<marcan>
_jannau_: adt.py prints your wifi password/serial/etc, but we already have all the "generic" ADTs available in the recovery partition etc
<marcan>
I'm not sure the wiki is the place for that though
<marcan>
way too big
<arnd>
Ah right, the mac mini has a Fresco Logic FL1100SX USB3.1 Gen1, using a single PCIe 2.1 lane. while ASM3142 uses two PCIe Gen3 lanes for USB3.1 Gen2 ports.
<_jannau_>
marcan: having the static information in the recovery partition for all models is good enough for me
kettenis_ is now known as kettenis
<kettenis>
the cheapest iMac doesn't have the ASM3142 chip I suppose?
yuyichao_ has quit [Ping timeout: 480 seconds]
GreatGodvin has joined #asahi
Ariadne has joined #asahi
choozy has joined #asahi
<arnd>
sven: I figured out the build failures with my nvme series
<arnd>
the only driver change I needed in the end is to include linux/dmapool.h, which is not implicitly included in all non-PCI configurations
<arnd>
the main change was rearranging parts of include/linux/pci.h so all the declarations are visible
<arnd>
the header uses an unconventional method of putting all its declarations inside of an #ifdef, and then having a small subset of them in the #else path as static inline helpers
<arnd>
normally we just make all those declarations visible in the kernel and only use the inline stubs for things that are commonly called but that can return an error code and have a working caller when the subsystem is disabled
GreatGodvin has quit [Quit: WeeChat 3.1]
<arnd>
I created a patch to add further inline functions, but on second thought I'm now removing the whole lot and just leave the declarations in place, with no inline stub. We'll see what breaks that way
<choozy>
What is planned as an installer if the M1 machines can not boot from external drives?
<sven>
arnd: nice! i've been looking into how to do all the apple-specific stuff. not sure if just declaring a quirk and then patching random places like corellium did is the right way.
<sven>
it might be enough to just use a different set of blk_mq_ops with two or so functions replaced
<sven>
not sure yet :)
<arnd>
sven: what kind of quirks are those?
<kettenis>
these apple "nvme" devices use some funky inear command queue instead of a ring
<kettenis>
s/inear/linear/
<sven>
needs a different nvme_submit_cmd (which is not part of any ops) and a different nvme_common_complete_rq (which is part of the queue ops) and some additional mmio pokes
<kettenis>
wonder if the queing mechanism matches the "NVMe-over-Fabrics" standard
<arnd>
ok, I see. That does seem quite invasive. We'll have to talk to the nvme maintainers anyway, to see if my approach for reworking the driver is what they want
<arnd>
sven: is this on top of the other appple-specific quirks that are already in the driver, or are those just for older hardware?
<sven>
it needs NVME_QUIRK_SINGLE_VECTOR and NVME_QUIRK_SHARED_TAGS
<sven>
(and possibly another one to not try nvme_scan_ns_list which always seems to fail)
<sven>
and yeah, it's quite invasive changes on top of the platform split :/
nskl has quit [Quit: WeeChat 3.1]
nsklaus has joined #asahi
<marcan>
just pushed a big reorg of proxyclient/ to clean up the hierarchy
<marcan>
choozy: curl|sh from recovery mode to install the bootloader, optionally install linux at the same time or use the bootloader to boot from an external drive
<marcan>
I probably just broke any wip trees people had making changes to proxyclient/ (or any non-pushed test scripts) so keep that in mind
<marcan>
I also cleaned up the namespaces a lot (no more a zillion unrelated things leaking into "from bla import *") so I expect I probably broke a bunch of stuff, but I tested all the basic experiments/tools to make sure they work
<fridtjof[m]>
it says there's an "NXP Semiconductor SN210V NFC controller with secure element" on there
<fridtjof[m]>
now, i couldn't find much about that chip, and they didn't link anything there, so it might not be an NFC controller at all (rather just a secure element maybe)
<fridtjof[m]>
but maybe someone with that imac can find out more? There does not seem to be an NFC antenna anyway, but it's still kind of interesting
aquijoule_ has quit [Ping timeout: 480 seconds]
yuyichao has quit [Quit: Konversation terminated!]
yuyichao has joined #asahi
<marcan>
fridtjof[m]: the iPads/etc have the same chip, and I bet all M1 macs do too (iFixit is nowhere near exhaustive/consistent with their chip IDs)
<marcan>
Apple do have external secure storage for anti-rollback; it might just be that
<fridtjof[m]>
ah, thanks. that makes sense then (i guess an nfc antenna would've been noticed by now anyway)
yuyichao has quit [Ping timeout: 480 seconds]
bps has joined #asahi
<marcan>
just pushed a thing for running hypervisor setup scripts from run_guest.py
<marcan>
so we can move away from hacking directly on hv.py
<marcan>
e.g. tools/run_guest.py -m hv/trace_agx.py <...>
<marcan>
all the modules share the same globals namespace, and anything you define in them is also available in the shell
<marcan>
also stuff persists across shell runs now
<marcan>
you can also run_script(<path>) from the shell to do it dynamically (e.g. edit-test cycle)
<Fanfwe>
marcan: anti-rollback as in you can't downgrade your OS ? Why would they care putting such a thing in a Mac then ? I mean they've made sure that the bootloader is not locked and that you can run 3rd party OSes, so why would they prevent you from downgrading Mac OS then ?
<marcan>
Fanfwe: anti-rollback as in you can't desolder the flash on your iPhone and take a backup, try 10 PINs, restore the backup, try 10 PINs, restore the backup, try 10 PINs, ...
<marcan>
(this is how the FBI cracks iPhones)
<marcan>
there are many security reasons to have rollback-protected storage
<Fanfwe>
Yup ok, that makes sense then
<marcan>
anti-downgrade *against the user's will* is another one of them - you can't downgrade Mac OS *bypassing* the normal attestation mechanisms for that reason too
bgb has quit [Ping timeout: 480 seconds]
<marcan>
Macs do have hard anti-downgrade for SFR though (that's iBoot1, the NOR/first stage bootloader and 1TR) but not OS installs. You can downgrade macOS (though you might need to go to reduced security once Apple stops signing that old version)
<marcan>
not sure how that's done though, it might be fuses and not the SE, no idea
<marcan>
the decoupling between iBoot1 and iBoot2 is useful to us, because effectively iBoot2 (and the associated firmware/ADT blobs) define the OS interface
<marcan>
that means we don't have to rush to support a new set of firmware interfaces/etc if Apple changes them in a way we don't support
<marcan>
we can continue to use the version of those components that we support
pinskia has quit [Remote host closed the connection]
<marcan>
(worst case we'll have to pull them from Apple's CDN directly though, in that case, since of course copying them from 1TR, which is my primary plan, won't work if we need an older version)
<marcan>
(nothing that can't be done in an installer though)
<Fanfwe>
Yeah, as long as users have a copy of it somewhere. Since I guess you can't distribute them without Apple permission.
<Fanfwe>
Yep, as long as Apple leaves them available on their CDNs, indeed
<marcan>
I think they usually leave these things forever on their CDN
<marcan>
either way we do intend to support newer versions (which probably have bugfixes etc)
<marcan>
it just means we don't need to panic when incompatible updates happen
<Fanfwe>
yup. Allright thanks for all those details !
<Glanzmann>
marcan: How is an anti rollback implemention to counter the fbi case you described above?
<Glanzmann>
implemented?
<brentr123[m]>
<Glanzmann "marcan: How is an anti rollback "> The fbi is the government lol, the government will always find a way no matter what
<brentr123[m]>
You can’t “counter the fbi”
<Fanfwe>
brentr123[m]: He didn't say "counter the fbi". He said "counter the fbi case [...] described above". Totally different.
<brentr123[m]>
Essentially the same thing I believe, trying to go around something the fbi can do either way
<brentr123[m]>
Or trying to patch out
<marcan>
brentr123[m]: the government are not magical, they cannot bypass math and physics
<brentr123[m]>
Gottem
<marcan>
Glanzmann: read apple's platform security guide :-) but there's an external secure element that implements the secure rollback-protected storage
<Fanfwe>
Yeah but the question was: "how does anti rollback allows to counter the fact that de-soldering the flash, backing it up, trying 10 pins, restoring the backup and keep trying until you find the right code is a working approach to pin cracking an iPhone (which, by the way, is something the fbi does)". The question was not "how to make it impossible for the fbi to crack a phone".
<marcan>
you can't make it "impossible" to crack a phone, but you can make it "hard and expensive enough that the FBI will give up"
<marcan>
which is what Apple aims for
<Fanfwe>
They won't give up, they'll ask a court to force you to help. And you can't either :D
<marcan>
hasn't worked in the past
<Fanfwe>
thanks god
<marcan>
the FBI tried, Apple said no, they had to give up and ask someone else; that someone else sold the FBU an exploit to open up the phone, then went on to found Corellium
<Glanzmann>
marcan: I see. But I did not get the concept how anti rollback helps against desoldering flash.
<Fanfwe>
You can desolder the flash, but it won't help as it is encrypted
<marcan>
(obviously this is all assuming no security flaws; security flaws happen but you can try to keep them at bay, and Apple's designs are really good these days)
<Glanzmann>
I was once in a forensic workshop where a russion company showed how many scrambling / encryptions algorithms they have implemented for hundreds of devices.
<marcan>
Glanzmann: if you try to rollback the flash contents the phone will reject it
<Glanzmann>
So they usually take the flash chip and work directly with that, without the controller.
<Glanzmann>
marcan: I see, now I got it.
<marcan>
the rollback counter is stored in a secure element which you can't just read/write like a flash
<Glanzmann>
Got the idea, thanks.
<Fanfwe>
Glanzmann: yeah, but the flash contents is encrypted, so you can try to work offline on the encrypted data, trying to find the key to decrypt
<Fanfwe>
or you can try to bruteforce a rather simple pincode
<marcan>
the phone will self destruct the data after a certain number of attempts
<marcan>
you cannot work offline on the encrypted data because the encrypted data is tied to a per-chip key
<Fanfwe>
the latter sounds much easier, but only if you have unlimited pin attempts
<Glanzmann>
Fanfwe: I don't remember the details, but most where only scrambled, not encrypted, and sometimes the encryption key was stores on the same flash or it was the same for all devices, IIRC.
<hell__>
something needs to verify flash chip contents, and that something isn't part of the flash chip
<marcan>
so you can't bruteforce the pincodes except on the device itself
<marcan>
and the anti-rollback ensures the hard limit on attempts
<marcan>
Glanzmann: most storage encryption (the "self-encryption" kind) is garbage and insecure
<marcan>
you cannot trust SSD/HDD vendors on any of this
<Glanzmann>
I see, so in apple the encryption key is stored in a secure enclave. It is only revealed wwhen the right pin is entered.
<hell__>
AFAIK roots of trust start inside the SoC nowadays
<Glanzmann>
If the pin is x times wrong it burns the secret key, end of storry.
<marcan>
the right pin is part of the key too, so you still need to figure out the right pin even if you magically get all the keys out
<marcan>
but otherwise yes
<Fanfwe>
I think it even wipes the data on the flash, in fact
<Fanfwe>
not just the key
<marcan>
it should just wipe the keys
<Glanzmann>
marcan: Yeah, that is what I learned, and you can't trust thunderbolt with your RAM. So best thing is to do it on the device as well as in software. :-)
<Fanfwe>
oh ok
<marcan>
they call it "effaceable storage"
<marcan>
you can trust thunderbolt with your RAM if there is an IOMMU (and the drivers use it properly)
<Glanzmann>
Fanfwe: WOuld make sense.
<marcan>
which is why I refuse to allow DART bypass for the TB ports in linux
<marcan>
(at least not without some scary sounding explicit parameters)
<Glanzmann>
marcan: I know, but often there is not or it is misconfigured.
<marcan>
yes and I'm going to make sure ours is there and properly configured :)
<Glanzmann>
I also heard storries of people hotplugging PCI devices in order to dump the RAM.
<marcan>
the internal PCIe port also has an IOMMU
<Glanzmann>
I see. Cool.
<marcan>
the M1 is, as far as security/compartmentalization, miles ahead of anything x86 (except maybe the xbox one)
<marcan>
all the coprocessors have IOMMUs
<marcan>
there is no secret ME or SMM or anything like that where you can hide a backdoor to take over the system
<Fanfwe>
yup, saw your thread about this on twitter few days ago
<sven>
fwiw, there's already nice infrastructure in linux to allow darts in bypass mode. if pci->untrusted (or something like that) is set it won't allow any iommu in bypass mode unless you force it to
<marcan>
you could theoretically backdoor the boot process on the main CPU, but the ARM design makes it very, very hard to do it undetectably (it's very hard to make a secret undetectable hypervisor or something like that)
<sven>
*disallow darts
<marcan>
sven: good :)
<sven>
all we need to figure out is a sane way to set that untrusted thing for the wifi chip :)
<kettenis>
sven: my plan is to add a node in the device tree for the wifi chip
<kettenis>
we need to have a place to store its mac-address
<marcan>
yes
<marcan>
so we should be able to set the untrusted thing there (add a binding if there isn't one)
<sven>
you can just set the pci bridge to external-facing, but that's ugly
<sven>
i think arnd mentioned it might be a good idea to find a general way to set this for all broadcom (or even all wifi) devices
<kettenis>
so if the generic of pci code in linux can handle a suitable property on that node, we should be alright
<Glanzmann>
marcan: I see. Nice to know. Btw. does Linux use the IOMMU if it is available by default on amd64 or does a user need to enable it explicitly?
<_jannau_>
marcan: might be a good idea to (re)tweet the stream announcement with the AsahiLinux account
<kettenis>
sven: the DT binding for the apple pcie controller already includes a node for the bridge corresponding to the root port
<kettenis>
so using "external-facing" there should already work
<arnd>
kettenis: it should work, but it feels slightly wrong, since it's not the PCIe port that is external facing, but rather the device that is hardwired to that port
<kettenis>
true
<kettenis>
but it would be a viable stopgap measure while you guys figure out how to handle the mismatched page size issue in the IOMMU code
<arnd>
Glanzmann: it depends on the iommu driver, and the CPU architectures. Most combinations support both strict and relaxed modes, but the defaults are inconsistent
<marcan>
_jannau_: good point, done :)
<arnd>
Glanzmann: on some architectures, using the iommu causes a fairly large overhead, so those would only be used if necessary to avoid bounce buffers, but fall back to bypass mode in other cases.
<Glanzmann>
arnd: I see, how can I check if my system currently uses the iommu?
<arnd>
Glanzmann: not sure. Usually you can find some output in dmesg, but there may be a generic interface for querying at runtime that I'm not aware of
<arnd>
drivers/iommu/iommu-sysfs.c tells me there should be something in /sys/class/iommu/, but all the x86 machines I'm looking at have nothing in there, so maybe they just have it disabled
<sorear>
What about Arm makes non-architectural extra hypervisors more difficult than other architectures?
<sorear>
or was this about malware not being able to use the architectural EL2
<marcan>
arnd: /sys/class/iommu should be there if it's enabled
<marcan>
it is on my systems
<marcan>
sorear: right, if you're in EL1 you'd notice
<marcan>
and there is no nesting support
<marcan>
faking it would be a ton of work
<marcan>
it's not really intended to be possible
<marcan>
I explicitly boot with intel_iommu=igfx_off though
<sven>
you want to look for /sys/kernel/iommu_groups/0/type
<sven>
if that file contains identity the iommu is in bypass mode
<sven>
(and there might be multiple groups)
<sorear>
I need to look into how nested virt works on arm, I take it it’s not just a matter of trapping and emulating EL2-only registers
<marcan>
the problem is you can't do that
<marcan>
ARM does not let you trap arbitrary registers
<marcan>
EL2-only registers trap to *EL1*
<marcan>
(as they are considered undefined instructions)
<marcan>
so in order to do this you need to do stuff like patch the EL1 exception vectors (which is what my hypervisor does...)
<marcan>
but then how are you going to trap stuff like CurrentEL?
<marcan>
so yeah, hardware NV support adds a whole pile of stuff to make this all possible
<marcan>
including things like redirecting sysregs to RAM
bgb has joined #asahi
<maz>
you could emulate NV my running everything at EL0. good luck with that.
<maz>
by*
<maz>
(and even by doing that, CurrentEL would still return the wrong thing).
<sorear>
CurrentEL is readable at EL0? ew
<maz>
yup, and it will always say EL0.
<sorear>
that had to have been very contentious
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
Andalu30 has joined #asahi
<maz>
sorear: contentious? why?
<sorear>
m68k and x86 started out with a CurrentEL mechanism but got rid of it later, a breaking change in the 68020’s case. they’re also saying about as directly as possible “popek/goldberg considered harmful”
VinDuv has joined #asahi
aleasto has quit [Remote host closed the connection]
Andalu30 has quit [Ping timeout: 480 seconds]
<maz>
sorear: the ARM architecture isn't virtualisable. not in the Popek/Goldberg sense anyway. even with NV2, it is all a massive hack that only allows a small portion of the architecture to be approximated.
aleasto has joined #asahi
<krbtgt>
iirc x86 never got rid of currentel
<krbtgt>
it just never was virtualizable according to P&G rules
<krbtgt>
it just pissed all over them
<krbtgt>
i.e yuou can load the MSW unprivleged
<krbtgt>
whereas 680*1*0 changed the ISA to make that privileged and thus comply to P&G
<krbtgt>
anyways the considered hamrufl is pretty interesting. i wonder why
<krbtgt>
i prob guess "it's bad for a guest to not know it's being virtualized"
Andalu30 has joined #asahi
<bloom>
considered harmful considered harmful
<hell__>
heh
<bloom>
considered harmful considered harmful considered harmful
<j_ey>
ad infinitum
<hell__>
.* considered harmful
<bloom>
considered helpful considered harmful
Andalu30 has quit [Read error: Connection reset by peer]
<jn>
considerations considered considerate
Gues_____ has joined #asahi
Gues_____ is now known as r0ni
<bfredl[m]>
harm is considered helpful
<bloom>
sadistic much?
* hell__
would go on, but notices /topic talking about keeping things on topic
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
* psydroid
considers the topic not to be harmful and notices people do try to be helpful and considerate
tsida has quit [Remote host closed the connection]
aleasto has quit [Remote host closed the connection]
TheJollyRoger has quit [Ping timeout: 480 seconds]