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
ransom has joined #asahi
shuffle2 has joined #asahi
<shuffle2>
is it possible on m1 to also have "secure boot" for non-apple OS (linux?)
<shuffle2>
also curious how much of the hardware security features (like AMCC lockdown/SEP/etc) can be used in linux
ransom_ has joined #asahi
<shuffle2>
presumably it has PAC as well, right?
<j`ey>
it has PAC yeah
ransom has quit [Ping timeout: 240 seconds]
stemnic has joined #asahi
<Shiz>
shuffle2: so right now it seems that any non-iBoot loader you have it run must be registered in the manifest with hash
<Shiz>
depending on the circumstances where it allows that to happen (my guess is 1TR, but not sure yet), further security is up to whatever second-stage loader runs after :)
stormclad has joined #asahi
<artemist>
The easiest way would probably be for mini or whatever to load u-boot and have u-boot do UEFI secure boot
<artemist>
Writing secure boot code is an absolute pain
ransom_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Shiz>
artemist: mini would still need to authenticate uboot :)
<artemist>
Oh, oops, I forgot to include that in my revised message
<artemist>
You could just SHA256 it and compare it to an internal hash
<Shiz>
also, does u-boot's EFI do secure boot?
<Shiz>
looks like it does as of 2020.10
<artemist>
You could also do AVB but that is awful to get working
<Shiz>
but yeah, u-boot also has its own framework so it might depending on your need also work
<artemist>
When I say compare it to an internal hash I mean "pull a nintendo and strcmp it"
<artemist>
/s
<shuffle2>
is there then a way to query/attest what the bootloader executed? (does whatever parses the manifest measure the hash into a PCR or something) or can that be used to unwrap keys to decrypt disk partitions, etc
<artemist>
I wouldn't be surprised if the SEP supported that but I also have no evidence that it does
gua has joined #asahi
<gua>
apologies if this was mentioned before, i'm just now watching the community chat on youtube, and about the USB C PD serial connection, the T2 / T2 on linux guys have a writeup: https://blog.t8012.dev/ace-part-1/
<gua>
posted on Dec 30. "Exposing Apple's Vendor Defined Messaging protocol, AppleVDM, built on USB-PD."
<gua>
one quick question shiz, do you think there's a chance that any of the asahi work will be relevant to say better audio support or SPI support in existing macs with T2 chips?
<gua>
or power management
<Shiz>
I doubt it
<Shiz>
audio or power management have very little to nothing to do with the T2 chip in those macs, afaik
<gua>
that's what i feared. seems that way. since the M1 is mostly iphone-esque.
<gua>
yes indeed
<artemist>
It could definately be useful for running Linux on the actual T2 but that's about it
<Shiz>
which is most of the common ground between those and m1 macs :)
<gua>
seems like the T2 macs might get slightly more attention for a year or two if the T2 on linux folks get enough upstreamed but seems like with the M1 macs displacing the T2 as the latest exotic platform, and more useful, the T2 might not get that much attention soon ;/
gua has quit [Remote host closed the connection]
gua has joined #asahi
ransom has joined #asahi
<rwhitby>
so it looks like two breakthroughs occurred overnight - 1) building on the testing of partition adding yesterday, a set of additonal partitions was identified which is recognised as an alternate boot target in 1TR, and 2) a means of running sshd in 1TR was identified. it would be good have these documented so others can reproduce and verify ...
<rwhitby>
2) seems to be a combination of master.passwd and UsePAM=no
choozy has quit [Remote host closed the connection]
<rwhitby>
the overnight log for 1) refers to needing at least an APFS volume group, Preboot volume, /Library/CoreServices/, /usr/standalone/, bless, apfs preboot update, Recovery volume, but not sure if all this was sufficient or if more was required.
<jn__>
i suppose a SW:Recovery or SW:1TR page in the wiki might be a good place for things like how to configure SSH
<rwhitby>
today I'm going to run DFU through an Ellisys C-Tracker USB-PD/USB analyser, capture the traffic, and report on whether there is any USB-PD traffic involved or whether it is all plain USB data.
<Shiz>
`sed -n 's/^_sshd/sshd/p' /etc/master.passwd >> /etc/master.passwd` should be a functional oneliner for adding back the sshd user btw
<davidrysk[m]>
the problem isn't that the sshd user is missing, btw — the problem is that whatever directory service feature that allows _sshd and sshd to map to the same user is nonfunctional in recovery
stormclad has quit [Ping timeout: 272 seconds]
<davidrysk[m]>
I started digging through that scaffolding but it's quite a lot of layers
<Shiz>
yeah
<davidrysk[m]>
I guess what I'm saying is that Apple didn't do it to make it harder for us but to slim down recovery
amw1 has joined #asahi
<Shiz>
I wonder if when you `dscl -read /Local/Default/Users/_sshd` it still has `RecordName: _sshd sshd`
<Shiz>
don't have access to my m1 to check :)
<brentr123[m]>
I would love to be a tester for you guys, as long as my Mac doesn’t Brick ;)
<rwhitby>
So my understanding of DFU restore for M1 is that I can completely wipe the internal disk, and run DFU restore from Apple Configurator 2 from another Mac (running the same OS version I believe), and get back to a clean install state. Has anyone here personally verified that before I try it here?
<Shiz>
well feel free to boot into 1TTR, pop a terminal and try that command :p
<Shiz>
also `ps -ef | grep directoryd`
<rwhitby>
Shiz: /usr/libexec/opendirectoryd is running
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ransom has joined #asahi
<robinp>
Shiz: I get "Cannot open remote host, error: DSOpenDirServiceErr"
<os[m]>
rwhitby: not tried it with M1 but the process seems identical to the restore process on Intel T2 macs and that is able to restore the Mac from any wipe or software fault I have experienced. So by following the instructions with Apple configuratior I'm fairly certain you can revive a m1 after a complete disk wipe without problems
<Shiz>
robinp: sorry, that should be `dscl . -read /Users/_sshd`
<Shiz>
forgot that the cli args are diff from the interactive shell args
<rwhitby>
os[m]: thx, I'm going to try it without wiping first, and then try it after deleting various volumes later
<rwhitby>
I want to get to a point where I'm 100% comfortable in having the internal disk wiped at any time for any reason and knowing that I can recover to a initial install state at any time.
ransom_ has joined #asahi
<robinp>
shiz: Yeah, still has `RecordName: _sshd sshd`
<Shiz>
that's good, I wonder if it still has the same mappings in /etc/openldap/AppleOpenLDAP.plist then
ransom has quit [Ping timeout: 264 seconds]
<robinp>
no /etc/openldap
<Shiz>
might explain some
<Shiz>
that file has the mappings for uid <-> DSCL keys iirc
<os[m]>
Since it mentioned specifically restoring recovery os i think you have nothing to worry about if you mess up the disk volume. The low level dfu afaik cannot be bricked since it's loading from an rom internally ( assmunimg M1 is like any other ios chip which I think is a fair assumption)
<rwhitby>
os[m]: yes, I 100% believe it will work, but need to verify it myself before I rely on it :-)
<Shiz>
I'm starting to think RestoreOS just means DFU
<Shiz>
actually nvm, seems they are distinc
<Shiz>
going back to my assumption that RestoreOS is loaded onto the device in DFU mode then to... restore stuff :p
<rwhitby>
I like that for the m1ni you don't need to hold down 4 keys at once, but just hold the power button while applying power and see the orange light for DFU entry.
<rwhitby>
Now, lets's see what the USBC cable requirements are. It should just be D+/D- connected through, so all passive cables should be fine, but going to see what happens with active TBT3 cables (not expected to work) and active USB4 cables (expected to work).
<rwhitby>
I take that back, active TBT3 cables will likely work too, unless they are active optically isolated cables.
ransom_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<os[m]>
Fun fact apple configurator and the process it mentioned is just a more limited version of the tool repair centers use where they are able to serialize new boards and calibrate replaced components
<Shiz>
apple configurator is mostly just a frontend for libimobiledevice, isn't it
<os[m]>
Have not looked into it that deeply but I would assume so. I know the internal tools have some frameworks which apple configurator does not come with
<Shiz>
that's a significantly older iboot than stage2
<Shiz>
(also, let's avoid talking about internal/leaked stuff and tooling here in general)
<Shiz>
rwhitby: 0x1227, so a known DFU protocol
<Shiz>
rwhitby: what's the product string?
<rwhitby>
DFU Functional Descriptor:
<rwhitby>
------------------------------
<rwhitby>
0x07bLength
<rwhitby>
0x21bDescriptorType
<rwhitby>
0x01bmAttributes
<rwhitby>
0x000AwDetachTimeOut
<rwhitby>
0x0800wTransferSize
<Shiz>
that was probably bette r fit for a pastebin :p
<rwhitby>
0x03iProduct "Apple Mobile Device (DFU Mode)"
<rwhitby>
oh, sorry, I'll pastebin stuff instead
<Shiz>
hehe, funny how it still says Mobile Device
<rwhitby>
interesting - in DFU mode, there is still a TBT3 connection made between the apple configurator 2 host and DFU M1 device. not sure yet whether it is used for anything though. only way to tell will be to do two DFU restores, one with a simple USB2 cable and one with a TBT3 cable and see if the restore time differs.
bear24rw has joined #asahi
bear24rw has quit [Client Quit]
bublik__ has joined #asahi
<rwhitby>
ok, it's just the PD messaging, there's no LSTX/RX traffic, so the TBT data path is not active
bublik_ has quit [Ping timeout: 264 seconds]
bublik__ has quit [Ping timeout: 256 seconds]
Bublik has joined #asahi
<rwhitby>
but what that does probably mean is that the USB-PD side of things can operate all the way to making a power contract (obviously needed for dead battery operation) and a TBT3 control connection without any interaction with macOS.
Bublik has quit [Ping timeout: 240 seconds]
<rwhitby>
ok, I confirmed that you can't DFU restore an 11.1 M1 device from a 10.15.7 host - it requires a system OS update to proceed. Moving to a different MBP host running 11.1 ...
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #asahi
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Shiz>
interesting
gua has quit [Remote host closed the connection]
<davidrysk[m]>
rwhitby: very interesting, I wonder why.
<marcan>
pretty sure the iBoot in NOR (SFW) cannot be rolled back
<marcan>
and so if it is too old it might not be compatible with whatever you're using to DFU
<marcan>
*SFR
Tokamak has joined #asahi
Tokamak_ has quit [Ping timeout: 260 seconds]
<Shiz>
I think the DFU stuff is just handled by MobileDeviceKit inside of Apple Configurator.app
<davidrysk[m]>
yeah, but DFU should be independent on what OS you're running on the host computer
<davidrysk[m]>
(as long as the host OS supports the latest Configurator)
<Shiz>
ah, which talks to MobileDevice.framework in /System/Library/PrivateFrameworks :)
<Shiz>
so presumably if that it outdated it may cause issues
Bublik has joined #asahi
<marcan>
ah yeah, that could just be some "avoid problems" thing and not a hard requirement
<Shiz>
MobileDevice.framework is fun to reverse, it confirms the theory on restoreOS I had
<rwhitby>
Configurator connects and sees DFU, but says you need to update the host before you can start a revive.
<rwhitby>
so the "Revive" step is pretty painless. It just asks you for the password for an admin user and then reuses the macOS install that's ostensibly untouched.
<Shiz>
might be because there's some version/dfu rom/etc check in MobileDevice.framework
<Shiz>
which causes it to be neeed to be updated for newer devices
<rwhitby>
Next is "Restore" which should replace macOS and wipe all data
<marcan>
oh also, one thing that just hit me: all this boot policy stuff is *per OS*
<marcan>
which means that, in principle, you can dual boot full secure macOS *and* Linux
<davidrysk[m]>
marcan: that was covered in the WWDC talk :)
<marcan>
which means you can run iOS apps (that gets locked out if you disable security)
<marcan>
so this is different from Android, where once you unlock the bootloader and flash an unsigned OS google wants to stop you from running certain apps
<marcan>
davidrysk[m]: I should watch that whole thing shouldn't I :)
<Shiz>
was gonna remark you probably don't wanna try this with m1 :p
<rootspring[m]>
Wen eta I device restore apple M1
amw1 has quit [Ping timeout: 272 seconds]
amw1 has joined #asahi
bitcoinr has joined #asahi
bitcoinr has quit [Client Quit]
bitcoinr has joined #asahi
bitcoinr has quit [Quit: Exit game!]
bitcoinr has joined #asahi
amw1 has quit [Ping timeout: 260 seconds]
<marcan>
rwhitby: it doesn't quite work yet
bitcoinr has quit [Read error: Connection reset by peer]
<marcan>
the volume layout is just the OSX one (you need OS/data/recovery(?)/preboot partitions)
<marcan>
but it doesn't successfully create the bootpolicy yet, working on that
<marcan>
I did confirm you definitely need the OS/data split, legacy single volume doesn't work with their process on apple silicon
<marcan>
going to work on that now
aratuk has joined #asahi
amw1 has joined #asahi
aratuk_ has joined #asahi
aratuk_ has quit [Read error: Connection reset by peer]
aratuk__ has joined #asahi
aratuk__ has quit [Remote host closed the connection]
aratuk_ has joined #asahi
aratuk has quit [Ping timeout: 264 seconds]
bitcoinr has joined #asahi
amw1 has quit [Ping timeout: 246 seconds]
aratuk_ has quit [Ping timeout: 264 seconds]
bitcoinr has quit [Read error: Connection reset by peer]
bitcoinr has joined #asahi
jamadazi has joined #asahi
Bublik has joined #asahi
<bitcoinr>
hello! newbie here
<rwhitby>
marcan: what's the smallest reversible deviation from fully secure that I can do to test that full security is restored by the DFU restore?
bublik_ has joined #asahi
<marcan>
rwhitby: I think at the very least you have to go to reduced security (bputil -g from restore mode)
<marcan>
since otherwise in principle it won't let you do anything
<rwhitby>
and after the restore, does bputil tell me that it's back in full security or is there another utility to determine that?
<marcan>
I think bputil -d will tell you, though I'm not sure in what format :-)
<marcan>
oh also, there is a GUI tool for this
bitcoinr has quit [Read error: Connection reset by peer]
<marcan>
startup security util or whatever
<marcan>
that should show you the current state
Bublik has quit [Ping timeout: 246 seconds]
bitcoinr has joined #asahi
<rwhitby>
ok, I see "Full Security enabled" before bputil -g and "Reduced Security enabled: 1" after
<rwhitby>
restart to check that is persisent, then a full restore to check it is reverted
Core8722 has joined #asahi
<rwhitby>
"bputil -g" is persistant across a restart in 1TR (as expected)
bitcoinr has quit [Ping timeout: 264 seconds]
bublik_ has quit [Ping timeout: 264 seconds]
TheJollyRoger has quit [Remote host closed the connection]
Core8722 has quit [Read error: Connection reset by peer]
<rwhitby>
and is reverted to full security by a DFU restore (also as expected)
<rwhitby>
fun fact: you need to have gone through macOS setup before you can use bputil again to change (as opposed to just report), since you need to be able to type an admin user password.
bitcoinr has joined #asahi
maor26 has joined #asahi
bitcoinr has quit [Read error: Connection reset by peer]
bitcoinr has joined #asahi
bitcoinr has quit [Client Quit]
bublik__ has joined #asahi
<rwhitby>
marcan: you can also see the security settings in the System Information in Hardware->Controller
<rwhitby>
and the iBoot version in there is iBoot-6723.61.3 which as Shiz says is well ahead of the DFU iBoot verson
<Shiz>
that's 10.1, i guess?
<rwhitby>
11.1
<Shiz>
right
bublik__ has quit [Ping timeout: 264 seconds]
<MaxLeiter>
whoops, sorry for the blank message, accident
<marcan>
rwhitby: yup, all working as expected
<marcan>
and yes, the password thing is a requirement too
<marcan>
really, this is all almost 1:1 with the Android experience (as I just tweeted)
<marcan>
buy a Pixel device, go through device setup, go into dev settings, enable OEM unlocking, now you can flash whatever OS you want
<marcan>
main difference is if you truly wipe an Android you brick it (unless you have secret vendor tools, possibly special cables, and this only works on some devices), while on Apple Silicon there is always DFU
<Shiz>
and per-volume security policies :p
<Shiz>
marcan: >We also need to keep the overall structure looking like macOS
<Shiz>
I'm very not convinced of this
<Shiz>
there's already pointers in the boot process that fuOS is treated differently
<Shiz>
(it has its own whole separate manifest and stuff)
<marcan>
if fuOS is going to be a thing at some point, it doesn't look like it's a thing right now
<Shiz>
it is in libbootpolicy.dylib
<marcan>
yeah but if it's not in any tools that doesn't help us
<Shiz>
but yeah, not in bputil yet
<marcan>
right *now* I'm going to work off of the assumption we need to go through the customkc hoops
<Shiz>
customKC also has its own manifest :p
<marcan>
if Apple makes life easier for us in the future I will be eternally grateful :)
<Shiz>
which is also not in bputil yet
<marcan>
but at least that's in the manpage
<marcan>
so it should be in bputil soon
<Shiz>
hre's hoping :)
<Shiz>
i'm kinda expecting them to drop at the same time, we'll see
<Shiz>
they seem very tied together/similar in infrastructure, see also the coih manifest item
<rwhitby>
Can't seem to run bputil on an external bootable disk
<rwhitby>
"Boot objects update failed ... Operation not permitted"
<rwhitby>
Volume has a space in the name, will check if that's the cause.
shawnj2[m] has joined #asahi
jamadazi has quit [Read error: Connection reset by peer]
jamadazi has joined #asahi
aratuk has joined #asahi
aratuk has quit [Ping timeout: 246 seconds]
<marcan>
success! I got it to "boot" "Linux" :-)
<marcan>
unfortunately, the next problem is there is no admin user in that OS partition to authorize downgrading security
<marcan>
(which I suspected might happen)
<marcan>
there's something broken about the personalization process (picks the wrong preboot path), but I was able to fix it with a silly symlink
<Raqbit>
Great! Project's done
<marcan>
the quotes matter.
Mary_- has joined #asahi
<Raqbit>
:P
bublik__ has joined #asahi
Mary_ has quit [Ping timeout: 240 seconds]
<marcan>
anyway, I guess for the time being I will resort to doing a proper macOS install, and punt reducing this process to later
<marcan>
this is also the kind of thing where there is room for Apple to make life easier for us in the future (hint hint nudge nudge) so it's not terribly if it's clunky initially
<marcan>
*terrible
<rwhitby>
I can confirm that you can have a full security external boot disk and a reduced security internal boot disk. You can't change the security on an external boot disk from bputil on the command line, but you can modify it using the "Startup Security Utility"
<marcan>
huh, that's odd
<marcan>
sounds like a bputil bug in that case
<marcan>
also, can you look at your internal volumes in recovery, after booting from the external disk?
bublik__ has quit [Ping timeout: 246 seconds]
<marcan>
in principle all the preboot stuff should get copied over, because iBoot can't *actually* boot from an external disk
<marcan>
but it'll be really interesting to see how that works
<marcan>
and where it gets copied
<rwhitby>
not sure what you mean
<rwhitby>
if I'm in recovery, I can look at both internal and external disks, no?
<marcan>
yes, but what I mean is that once you have booted the external OS at least once, there should be stuff from that external OS copied to the internal SSD *somewhere*
<marcan>
and I'd like to know where and how
<marcan>
presumably at least part or all of the Preboot volume
<rwhitby>
I don't see any additional volumes on the internal disk
<rwhitby>
the external disk also has Preboot, Recovery and VM partitions, just like the internal disk
<rwhitby>
are you wondering what happens if I wipe parts of the internal disk, but still boot from the external disk?
<rwhitby>
my next text is internal and external is reduced security, and then DFU restore internal, and see if external remains reduced security
<rwhitby>
s/text/test/
<marcan>
look at iSC too
<marcan>
remember diskutil hides things from you
<rwhitby>
how do I see the full picture?
<marcan>
diskutil list -plist shows most things (but in plist format)
<marcan>
or just look for everything under /dev/disk*
<marcan>
and then run diskutil info on each
<rwhitby>
ok, in a while I'll have a restored internal disk, and a previously booted external disk. I'll capture the internal layout, then immediately try booting the external before doing first setup on internal, then capture internal layout again.
<marcan>
in particular, just run `find /System/Volumes/iSCPreboot` and see if there is anything other than LocalPolicy (a couple img4 files per dir) and SFR/ related stuff
<marcan>
it could be in there or it could be a separate volume
<Shiz>
i'm curious how that bootpolicy looks like too
* rwhitby
afk ~2h
<Shiz>
there must be some switch in there to denote it's fake-external
<marcan>
not necessarily, if it just boots from an internal partition I guess?
amw1 has joined #asahi
<Shiz>
yeah but then you'd have a vuid mismatch
<marcan>
yeah but I'm not sure how that gets passed to darwin
<Shiz>
depending which parts of the boot process care about that
<Shiz>
:p
<marcan>
yeah
<marcan>
but I mean, it could be two things in the boot policy, vuid of the preboot volume and vgid to boot
<marcan>
have you dumped those img4s yet?
<marcan>
though I guess it only has the vguid, hm
<Shiz>
yeah i have
<Shiz>
see the SW:Boot wiki page
<Shiz>
I documented the stuff there :p
amw1 has quit [Ping timeout: 265 seconds]
<marcan>
cool
<marcan>
wonder if those external boots then get another key
ky0ko has quit [Remote host closed the connection]
vimal has quit [Quit: Leaving]
bublik__ has joined #asahi
bublik_ has joined #asahi
bublik__ has quit [Ping timeout: 264 seconds]
<marcan>
Shiz: bputil actually doesn't default to anything, if you have more than one volume it prompts :)
<Shiz>
oh huh
<Shiz>
If no option is specified, the default value will be set to the APFS Volume Group UUID of the running OS. The Volume
<Shiz>
Group UUID for a given OS can be found with 'diskutil apfs listVolumeGroups'.
<Shiz>
from man bputil
<Shiz>
that obv won't work if in 1TR though
bublik_ has quit [Ping timeout: 256 seconds]
<marcan>
yeah that's what I meant
<Shiz>
badly-worded from my side
<marcan>
so now I'm tempted to just try hacking this with python
<marcan>
if it works, I might be able to set up customkc before official support, and it'll be useful for future similar experiments
<marcan>
if it doesn't, we know it won't
Tokamak has joined #asahi
<marcan>
by the way, this is the current sshd problem: Jan 10 10:11:51 fuwa sshd[398]: fatal: chroot("/var/empty"): Operation not permitted [preauth]
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
meh, annoying, apple's 11.0.1 drop has openssh 7.1 but the current version is 8.1p1
<Shiz>
fuwa~
<marcan>
chroot itself seems to work (in the terminal) so it's not some security stuff
<Shiz>
also as the sshd user? :p
<marcan>
actually wait
<marcan>
ah but this is just for execve
<marcan>
2021-01-10 10:20:24.026893+0000 0x1106 Default 0x0 0 0 kernel: (AppleMobileFileIntegrity) AMFI: hook..execve() hardened runtime not allowed in chroot
<marcan>
2021-01-10 10:20:24.026914+0000 0x1106 Default 0x0 0 0 kernel: (AppleMobileFileIntegrity) AMFI: hook..execve() killing pid 416: not allowed in chroot
<marcan>
I *think* that's ok?
<marcan>
sshd should only be chrooting and then doing ~nothing with the OS AIUI
<marcan>
by the way, another problem with using binaries from macOS is the dyld_shared_cache...
<marcan>
and also python wants a Python thing (which isn't in the cache thankfully) but DYLD_LIBRARY_PATH isn't helping
<marcan>
# /Volumes/Linux/usr/bin/python2.7
<marcan>
dyld: Library not loaded: /System/Library/Frameworks/Python.framework/Versions/2.7/Python
<Shiz>
yeah, lot of library paths in macOS are hardcoded static
<Shiz>
marcan: this is where'd you want to use install_name_tool
<sven>
or just give up on python and switch back to perl :-P
<marcan>
install_name_tool sounds like it's going to break signatures :p
<Shiz>
that's a fair point
<marcan>
does perl actually have a dynamic ffi that works on macos?
<Shiz>
somewhat surprisingly apple didn't package perl with an accompanying framework...
<marcan>
perl is in recovery
mrgs has quit [Remote host closed the connection]
aratuk has joined #asahi
<Shiz>
marcan: consider DYLD_FRAMEWORK_PATH?
<Shiz>
as well as DYLD_ROOT_PATH
<Shiz>
(wouldn't surprise me if the latter was locked down now)
<marcan>
doesn't seem to work
aratuk has quit [Ping timeout: 260 seconds]
brinly has joined #asahi
TheJollyRoger has quit [Ping timeout: 240 seconds]
DarthCloud has quit [Ping timeout: 240 seconds]
frode_0xa has joined #asahi
frode_0xa has quit [Client Quit]
TheJollyRoger has joined #asahi
DarthCloud has joined #asahi
frode_0xa has joined #asahi
frode_0xa has quit [Remote host closed the connection]
frode_0xa has joined #asahi
raster has joined #asahi
bublik_ has joined #asahi
bublik__ has joined #asahi
bublik_ has quit [Ping timeout: 260 seconds]
bublik__ has quit [Ping timeout: 260 seconds]
aimileus has joined #asahi
dpatterbee[m] has joined #asahi
ephe_meral has joined #asahi
amw1 has joined #asahi
amw1 has quit [Ping timeout: 256 seconds]
<davidrysk[m]>
marcan: what exactly do you need in recovery?
<marcan>
well it would be nice if we could actually run code that calls frameworks
<justMaku>
Cant you chroot?
<justMaku>
To get those frameworks in the right płace?
ephe_meral has quit [Ping timeout: 272 seconds]
<davidrysk[m]>
Btw I’m kinda frustrated that Apple still hasn’t updated their platform security documentation for M1
<davidrysk[m]>
But that’s probably one of the many things that’s dragging out
<sven>
wouldn't surprise me if that document is stuck somewhere in their marketing/pr department waiting for approval
<davidrysk[m]>
marcan: the login creds that bputil wants in Recovery are the login creds of an administrative macOS account
<davidrysk[m]>
The fact that with a Mac without macOS set up there is no such account is an oversight that I very much doubt will be fixed soon
aratuk has joined #asahi
bublik__ has joined #asahi
bublik_ has joined #asahi
aratuk has quit [Ping timeout: 246 seconds]
bublik__ has quit [Ping timeout: 256 seconds]
bublik_ has quit [Ping timeout: 256 seconds]
ephe_meral has joined #asahi
qyousef has quit [Quit: WeeChat 2.8]
qyousef has joined #asahi
<marcan>
justMaku: chroot does not work to actually run ejecutables due to amfi
<marcan>
davidrysk[m]: but when you do a normal boot picker selection of an "alien" macos partition, or when you *install* macos, it asks you for an account on the *other* macOS partition before doing all the provisioning
<marcan>
so there is clearly some security model path that says "existing users on another OS are allowed to provision a new OS"
<marcan>
so the question is can we combine those two: can an existing user on another OS provision a new OS *with downgraded security from the get go*
<davidrysk[m]>
is it "as long as the OS has already been provisioned"?
bublik_ has joined #asahi
bublik_ has quit [Remote host closed the connection]
<marcan>
what do you mean?
bublik_ has joined #asahi
<marcan>
also, alternatively, we could figure out if there is a way to convince everything that a user was set up in the new OS without actually booting it
<davidrysk[m]>
meaning, that macOS has to be provisioned to allow its users to provision a new OS
<marcan>
well its users need to exist in SEP-backed credential storage I assume
<marcan>
but the use case I have in mind is simply dual booting
<marcan>
without doing a dummy macos install
<marcan>
right now, it doesn't matter if you want to dualboot or not; either way you have to do a full-fat install of macos first (if you want to dual boot, you need to do that *in addition* to your normal macos partition), then replace it with linux, then maybe delete all the junk and files and shrink the partition if you want to reclaim the space, which is a PITA
<davidrysk[m]>
Yes, that's what I was going to say, I think the user creds go into the SEP
<marcan>
if you could use an existing user to provision a new OS in permissive mode, then for dual boot users, you could just provision linux without ever going through the full macos install
<davidrysk[m]>
the fact that bputil can't work on a Mac without an OS because of no credentials is a bug
<davidrysk[m]>
where do you get the existing user without installing macOS?
<marcan>
yes but when "installing" macOS or importing a foreign macOS (which is what I did when I copied chunks of it by hand) the boot policy gets created for you, without a user or with an existing user on the other macOS
<davidrysk[m]>
(also the computers already have macOS on them, and doing DFU restore puts macOS back, though out-of-the-box setup of macOS does require agreeing to the EULA which some will find objectionable)
<marcan>
so we know bputil refuses to work
<marcan>
the question is, is this also baked into the underlying protocol
<marcan>
or, if we can figure out a way to run arbitrary code in 1TR, can we just build a different flow ourselves
<marcan>
and make it work
<marcan>
so the tools apple gives us can either 1) provision a new or foreign, full-security OS, blank without creds, and 2) downgrade the security of an OS, with creds
<marcan>
and my question is, does the underlying SEP security model allow for 3) provision a new or foreign, reduced-security OS, blank without creds
<marcan>
it well might and the tools just don't implement it
<marcan>
this would also in principle allow for avoiding the phone-home requirement
<marcan>
since that also is something that only comes along with full security
<marcan>
but I can't claim to fully understand their security model here
qyousef has quit [Quit: WeeChat 2.8]
ephe_meral has quit [Ping timeout: 240 seconds]
qyousef has joined #asahi
<davidrysk[m]>
Part of the model is that the boot policy is signed by the SEP
<davidrysk[m]>
which means a foreign boot policy that specifies reduced or permissive security would be rejected
<marcan>
yes but there are at least two flows here with the SEP
<marcan>
it will sign a boot policy for a new OS, without existing credentials for it (obviously), with full security
<marcan>
and it will resign such a policy with permissive security, given that OS's credentials
<marcan>
so my question is, can it do both at once
<marcan>
e.g. can you ask for no security up front, and get it
<davidrysk[m]>
That would likely be a CVE
<marcan>
why?
qyousef has quit [Ping timeout: 240 seconds]
<marcan>
the security is based on data volume encryption
<davidrysk[m]>
because it circumvents anti-downgrade protection, which could lead to the ability to bypass Activation Lock and similar mechanisms
konstater has quit [*.net *.split]
<marcan>
it could still require personalization before signing such a boot policy, even if it does not enforce it at runtime
<davidrysk[m]>
True
<marcan>
we know the personalization ticket is checked during boot policy creation
<marcan>
(because that's what was failing for me due to some glitch in personalization putting the file in the wrong place)
ponikrf[m] has joined #asahi
frode_0xa has quit [Remote host closed the connection]
bublik_ has quit [Ping timeout: 246 seconds]
qyousef has joined #asahi
Bublik has joined #asahi
ephe_meral has joined #asahi
<thecake21[m]>
I may have missed something here. Why is it necessesary to create another macOS installiation and replace it with linux. Did the plan for how boot was going to work work change or is this just something temporary?
Daniel has joined #asahi
Daniel is now known as Guest12911
Bublik has quit [Remote host closed the connection]
Bublik has joined #asahi
Guest12911 is now known as dpatterbee
<marcan>
thecake21[m]: because the current macos custom kernel flow requires it
dpatterbee has quit [Quit: Leaving]
<marcan>
it's unclear if we have a way around this or if we depend on Apple to implement a better flow
<marcan>
the plan for how boot works has not changed, more like we understand better what the requirements are now
<marcan>
the tools that apple provides allow for *replacing* the kernel of an existing OS with a custom one, and crucially, that operation must be authenticated *by a user created on that existing OS*. that means that we cannot just "fake" an OS, because we have to actually boot it to create a user that can authenticate that operation
<thecake21[m]>
ah ok that makes sense now
<marcan>
I think there are enough nice people at Apple that, if nothing else, once this all gets off the ground and people are actually using it, there's a chance a better flow will be implemented :)
<marcan>
I mean they went through all the trouble to do this customkc thing, it's not like they don't *want* people running their own code
<marcan>
as long as whatever they do doesn't weaken their security model
<marcan>
but we'll see
<marcan>
so yeah, if anyone wants a side challenge... see if you can run arbitrary code (i.e. call functions in frameworks) from 1TR somehow
<marcan>
there's perl, not sure if that can call FFI; you can run signed binaries from macOS, but dyld complains about anything that needs a dylib/framework not inside 1TR itself, and I can't get it to use any macOS libs
<marcan>
but I'm a total macOS newb so what do I know
<marcan>
not going to pursue that much myself for now, but if it can be done it might open up a lot of possibilities
<davidrysk[m]>
does DYLD_INSERT_LIBRARIES work in 1TRR?
<davidrysk[m]>
(also is initial testing in x86_64 recovery useful?)
<marcan>
that wouldn't help seeing as presumably that library would have to be signed?
<marcan>
I couldn't get any evidence that dyld was listening to *any* env vars
<davidrysk[m]>
right, the signatures aren't just embedded in the shared cache.
<davidrysk[m]>
there is a DYLD_SHARED_CACHE_DIR var
<davidrysk[m]>
(according to the dyld(1) manpage)
<marcan>
I tried that, but it didn't seem to help?
<davidrysk[m]>
did you also use DYLD_SHARED_REGION=private?
<davidrysk[m]>
I'm guessing yes
<davidrysk[m]>
so I do wonder if the dyld in recovery is different
<davidrysk[m]>
oh yeah
<davidrysk[m]>
will a developer signed executable run in 1TRR?
<davidrysk[m]>
(as opposed to an apple-signed or an adhoc-signed)
<marcan>
I don't think so
<marcan>
but feel free to try :)
FFY00 has quit [Read error: Connection reset by peer]
TheJollyRoger has quit [Write error: Connection reset by peer]
DarthCloud has quit [Remote host closed the connection]
raster has quit [Quit: Gettin' stinky!]
DarthCloud has joined #asahi
jamadazi has joined #asahi
ephe_meral has quit [Read error: Connection reset by peer]
<Shiz>
fwiw, I'm fairly sure there's a macOS security policy thati gnores a bunch of dyld variables
<Shiz>
which might explain some of the issues
<Shiz>
as part of the hardened runtime
eric_engestrom has joined #asahi
aratuk has joined #asahi
TheJollyRoger has joined #asahi
addcninblue has joined #asahi
aratuk has quit [Ping timeout: 264 seconds]
ransom has joined #asahi
<davidrysk[m]>
Shiz: they're all ignored for codesigned code
<Shiz>
i've only seen docs to the effect of ignoring it for hardened runtime code
<Shiz>
yeah, the python codesigned binary has no entitlements
<Shiz>
so that's not it either
<davidrysk[m]>
the flags don't seem to work on macOS though
<davidrysk[m]>
but they do work for self-compiled code
<davidrysk[m]>
okay, hardened runtime does disable it
<davidrysk[m]>
hm, what if you just replace the entire dyld cache with the one from OS?
<davidrysk[m]>
I know that's a big-hammer sort of approach... and there might not be enough room on the recovery partition without deleting stuff
<davidrysk[m]>
also it might be protected from replacement
<marcan>
davidrysk[m]: we cannot touch binaries on the recovery fs
<marcan>
only var stuff is mounted tmpfs
<marcan>
and obviously the whole thing is going to be sealed too
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
thelounge05 has joined #asahi
raster has joined #asahi
thelounge05 has quit [Client Quit]
djhuk has joined #asahi
ransom has joined #asahi
jos_ has joined #asahi
jos_ has quit [Client Quit]
<davidrysk[m]>
marcan: question, gonna step back a little here and ask... what level of tooling are you planning that you want python in 1TRR?
<davidrysk[m]>
1TR rather, I keep getting that wrong
<Shiz>
it'd be a nice to have a one-step script to install Asahi from 1TR
<marcan>
the thing is if we can use FFI to invoke frameworks, we can probably solve the needing-macos-installed-first problem
<marcan>
exactly
<Shiz>
we need to be in 1TR *anyway* to apply the boot policy
<davidrysk[m]>
Perl doesn't give you a good way to invoke C functions without compiled external modules
<tbodt>
are any other programming languages available?
<Shiz>
python and ruby aren't at least
<Shiz>
there's tcl maybe?
<Shiz>
marcan: i just realised you might be able to get some otherwise-hard stuff also done with... applescript
<tbodt>
osascript is included?
<marcan>
it is not
<tbodt>
tcl doesn't appear to have built-in ffi either
<davidrysk[m]>
you don't need osascript to run applescript, but you need to precompile the applescript
<davidrysk[m]>
they might have disabled apple events, but apple events are used within the OS
<Shiz>
precompile as in, create a mach-o?
<davidrysk[m]>
however, they did add a ton of security tooling that blocks inter-process apple events by default
<davidrysk[m]>
oh, right. :)
<tbodt>
anything with a user-controlled NSPredicate?
<davidrysk[m]>
I meant a applescript
<davidrysk[m]>
.applescript*
<Shiz>
bleh
<davidrysk[m]>
okay... applescript is uncompiled, I believe .scpt is but for that you need osascript
<davidrysk[m]>
so, bleh
<davidrysk[m]>
there is no tcl
<davidrysk[m]>
(that I can see)
<awordnot>
what mechanism is used to allow things like csrutil to work in 1TR but not normal macOS? Is it just an arbitrary restriction in the kernel that blocks interfaces if it doesn't detect that it was booted in recovery?
<marcan>
csrutil changes the boot policy, which is SEP-signed; same thing bputil and kcutil touch
<marcan>
the SEP knows the boot mode
<marcan>
so there is no way around this restriction by design
<awordnot>
oh, I see, it's enforced by the coprocessor. I thought you might be able to patch the normal macOS kernel to disable the restrictions but I guess not
<davidrysk[m]>
marcan: have you tested if bputil requires user authentication on a freshly DFU’d Mac?
raster has quit [Quit: Gettin' stinky!]
<krbtgt>
minor correction on the website: there's a "fully open" system - talos ii. though it might depend on your def
merbanan has quit [Ping timeout: 272 seconds]
maor26 has quit [Ping timeout: 264 seconds]
<marcan>
krbtgt: talos ii doesn't even have open schematics (only owners get them, so they are not permissively licensed)
<marcan>
nevermind things like CPU microcode and other ROMs, or deeper levels like the HDL itself
<jn__>
krbtgt: if you consider all the programmable parts (software, firmware, fpga gateware) - yes (AFAIK). chip designs - no
<davidrysk[m]>
the FSF has this idea that closed firmware that can't be rewritten by software does not make a device non-free
<marcan>
people who say they are "fully open" are making up a very specific definition of "fully open" that they happen to meet
<davidrysk[m]>
which I think is ridiculous
<marcan>
the FSF is insane
<davidrysk[m]>
in general "fully open" is an ill-defined term
<marcan>
they are the bane of the modern fight for hardware freedom and they should be completely disqualified and their RyF program ignored
<marcan>
they don't have the slightest idea what they're doing and have lost all credibility
<krbtgt>
yeah purism made a mockery of RYF
<marcan>
RYF was always silly, purism just proved it
<marcan>
stallman has forgotten his own motivation for freedom; he wanted to patch a printer driver. he wanted his printer to work. it was a real, practical thing
<artemist>
The Freedom in "RYF" actually just means FSF, it means that you paid the FSF
<marcan>
now it's all some religious nonsense about Freedom™ with no regard for what is actually good for users
<marcan>
artemist: it's actually worse than that
<jn__>
sfconservancy seems much more grounded in practical issues
<marcan>
the Freedom in "RYF" actually means you are free to mentally delude yourself into thinking you're free, because all proprietary firmware has been hidden away from you
<marcan>
(even thought that means you are, in fact, less free, as ignorance is the antithesis of freedom)
<marcan>
it is all, honestly, downright troubling
<artemist>
I love how all the "Freedom" stuff Stallman does just means that computers work less instead of more
<marcan>
krbtgt: but as I mentioned on HN previously, yes, Talos is as free as it gets software-wise these days - e.g. I think they're the only modern platform with fully open source DRAM training
<marcan>
I just wouldn't stick any absolute "fully free" nonsense label on them. They're pretty good, go buy a Talos.
<marcan>
(if you have the money :))
<artemist>
I would love to get nixos running on one but money
<Shiz>
i may have just spent 150eur i could've put towards a thalos on some tshirts and a lego 911 car instead, no regrets
<jn__>
Shiz: a tenth of a talos board wouldn't be good for anything, anyway :)
<artemist>
Does any browser have a powerpc64 JIT?
<artemist>
I wonder how much stuff breaks on big endian
<davidrysk[m]>
marcan: what pathways are you currently looking at for doing more from 1TR?
<davidrysk[m]>
Shiz: some of the comments on that LWN article are interesting :)
<Shiz>
davidrysk[m]: cool to see someone grok the concept of negative liberty :)
<jn__>
davidrysk[m]: wow, this active makes the wifi fw loader harder to audit
<davidrysk[m]>
note that this article is from 2011
<davidrysk[m]>
but yeah they're still doing this
<TheJollyRoger>
artemist: Chromium on PPC64LE has Just In Time Javascript, but upstream doesn't like to play well with us so one of the people at the channel has maintained the patchset themselves.
<TheJollyRoger>
since upstream won't take them.
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<TheJollyRoger>
It works great though.
<TheJollyRoger>
I bought a Talos II to replace a beat-up old PC that I bought years ago and that was starting to fall apart at the seams. I like it, it's fast and powerful. It took a little bit of work to set up, but what computer doesn't?
amw1 has joined #asahi
bublik_ has joined #asahi
Bublik has quit [Ping timeout: 260 seconds]
aratuk has joined #asahi
aratuk has quit [Ping timeout: 246 seconds]
raster has joined #asahi
<rwhitby>
davidrysk[m]: if you run bputil on a freshly DFU'd device, it asks for the password for an install user (I forget the specific username but I can get it again later) and you don't know that password.
<davidrysk[m]>
is it _mbsetupuser?
bublik_ has quit [Remote host closed the connection]
bublik_ has joined #asahi
Bublik has joined #asahi
amw1 has quit [Ping timeout: 240 seconds]
bublik_ has quit [Ping timeout: 260 seconds]
amw1 has joined #asahi
modwizcode has quit [Quit: Later]
amw1 has quit [Ping timeout: 246 seconds]
amw1 has joined #asahi
<Alex[m]17>
when people say things like 'install asahi', is asahi the kernel itself, or is it a distro? or neither?
<Alex[m]17>
ok, so its an ALARM derivitive, kind of like Manjaro ARM
<j`ey>
thats not really the goal of it though
<davidrysk[m]>
it's more of a project to bring Apple Silicon support to the Linux kernel and provide tooling and a bootloader
<j`ey>
"We expect that support will eventually trickle up and back down to other distributions. Advanced users will always be free to use the distribution of their choice and add the necessary patches/software themselves before this happens."
amw1 has quit [Ping timeout: 256 seconds]
<jn__>
Alex[m]17: boring and terrible answer: probably depends on context and the person saying it
<brentr123[m]>
but a arch linux arm "remix" will eventually be made
<Alex[m]17>
ok, this makes sense, but if its just a project im confused when people say things like 'install asahi' if what we are really doing is installing linux and asahi is just a means to get to that point
<j`ey>
yes
<davidrysk[m]>
where are people saying that?
<jn__>
it might mean, for example, "install a linux system (which includes a kernel, and may also include userspace), which uses code from the asahi project"
<Alex[m]17>
i've seen it a few times in this chat, e.g. "it'd be a nice to have a one-step script to install Asahi from 1TR" is the latest example. i'm not trying to be rude or anything just looking for further clarification and i got it. thanks all
amw1 has joined #asahi
<jn__>
Alex[m]17: ok, in this example, my last interpretation seems to apply
<davidrysk[m]>
Alex: I think it means to install whatever the project puts together (Arch Linux ARM + Asahi bootloader/kernel/etc)
<jn__>
^
<Alex[m]17>
very cool. and i think ALARM is a great base for a project like this i've used it for a few months on a couple of my machine and have been very happy with it, despite its somewhat 'unofficial' status as a distro
amw1 has quit [Ping timeout: 256 seconds]
<Alex[m]17>
i have it on good authority that its basically for pkg in "${x86_64_pkgbuilds[@]}"; do cd pkg && makepkg -A && cd ..; done
<davidrysk[m]>
for the most part; some stuff is patched as needeed
<davidrysk[m]>
needed*
<davidrysk[m]>
and it's more work for the kernels, obviously
<davidrysk[m]>
For all too many ARM platforms, support isn't upstreamed :(
amw1 has joined #asahi
amw1 has quit [Ping timeout: 264 seconds]
amw1 has joined #asahi
<Alex[m]17>
yeah, i dont see this being upstreamed any time soon, so it might be useful to start thinking about hosting Packages for using Arch Linux ARM on the M1 devices such that we can add the repo it to our pacman.conf so that we can install and manage kernels, bootloaders + other important things we need to get things running.
<Alex[m]17>
* yeah, i dont see this being upstreamed any time soon, so it might be useful to start thinking about hosting Packages for using Arch Linux ARM on the M1 devices such that we can add the repo to our pacman.conf so that we can install and manage kernels, bootloaders + other important things we need to get things running.
frode_0xa has quit [Quit: leaving]
amw1 has quit [Ping timeout: 264 seconds]
amw1 has joined #asahi
amw1 has quit [Ping timeout: 256 seconds]
ransom has joined #asahi
jamadazi has quit [Read error: Connection reset by peer]
jamadazi has joined #asahi
amw1 has joined #asahi
raster has quit [Quit: Gettin' stinky!]
amw1 has quit [Ping timeout: 240 seconds]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]