<Bluerise>
Hi. Just wondering, has anyone here ever talked about porting U-Boot?
<Bluerise>
I see agraf is here
<Bluerise>
Just don't want to start duplicate efforts.
<jn__>
Bluerise: the (IMO) interesting parts of uboot, like raminit, are handled by iboot and AFAIUI you can't replace it
kettenis has joined #asahi-dev
<j`ey>
jn__: isnt the interesting bit being able to load a kernel? :P
<jn__>
porting uboot for non- hardware specific parts would be possible, i suppose. haven't seen talk of that.
<kettenis>
yeah, the context here is loading an OpenBSD kernel
<Bluerise>
no, the interesting part is: u-boot provides nvme + usb drivers and an EFI interface to boot other OSes
<kettenis>
OpenBSD/arm64 uses UEFI
<Bluerise>
yup
<j`ey>
it *needs* uefi?
<kettenis>
well, not really
<dhewg>
it also makes sense for linux. the distro needs a way to tell the bootloader which kernel version to boot, and the infrastructure is there for u-boot
<jn__>
oh, i remember some uefi talk in here, where uboot was mentioned
<kettenis>
however, the bootloader needs full device access to load random stuff
<dhewg>
it also has filesystem drivers to load a kernel off those
<kettenis>
and UEFI makes that very easy
<Bluerise>
yup
<Bluerise>
and for the user: he'd have to supply u-boot as "macos kernel" once
<Bluerise>
and can then boot whatever distro he likes from usb or hard drive
<Bluerise>
since u-boot can basically boot anything
<j`ey>
it's been discussed, but I dont think anyone has started on it
<Bluerise>
ok
<kettenis>
I'll probably see if I can make a start on that
<kettenis>
'cause I'm getting tired of reinstalling the macho bundled OpenBSD kernel over and over again ;)
<j`ey>
kettenis: have you got a fork with your changes?
<j`ey>
kettenis: you could also try use m1n1, if you have the right hardware, or can make/get one
<kettenis>
don't have the right hardware unfortunately
<j`ey>
could ask marcan, he was going to make some
<kettenis>
I'm past the point where I really need something like m1n1 ;)
<Bluerise>
hehe
<kettenis>
although a remote reset would be nice ;)
<Bluerise>
kettenis: if you do u-boot, I do the pmgr clock gate (should be simple)
<kettenis>
cheat!
<Bluerise>
:P
<Bluerise>
I can also try u-boot, but only one of us should
<Bluerise>
Need pmgr for dwc3
<j`ey>
kettenis: well m1n1 gets you a way to reset and reflash without the macho stuff
<j`ey>
kettenis: so is there a fork of OpenBSD somewhere?
<Bluerise>
no, we just use plain openbsd
<kettenis>
we don't do forks ;)
<j`ey>
well fork as in, somewhere you have changes
<kettenis>
currently it needs one tiny little patch to fake a Linux kernel header
<marcan>
Bluerise: m1n1 is already going to be a bootloader
<marcan>
that's the entire point
<marcan>
it'll load a kernel from FAT32 (just because that's easy)
<Bluerise>
will mini gain efi support?
<j`ey>
kettenis: so you made no changes to openbsd?
<marcan>
no, I'm definitely not going to reimplement EFI
<marcan>
if OpenBSD needs UEFI, then it should use a second stage chained loader that does that
<marcan>
m1n1 could be taught to boot u-boot in whatever format it gets built in, quite easily
<kettenis>
@marcan: we need an API to access raw disk such that we can read files from an OpenBSD UFS/FFS filesystem
<marcan>
and if u-boot reaches the point where it supersedes m1n1 for typical users then that's fine too, that depends on how things go in the long term
<Bluerise>
j`ey: a) the only diff is an assembly header that fakes a linux kernel header b) the rest does either not exist yet or is/will be committed straight to openbsd
<kettenis>
anyway, nothing exciting yet
<kettenis>
the OpenBSD kernel boots and has a framebuffer console
<marcan>
basically my current approach is: m1n1 is the first stage loader, and I want to shove as much M1-specific junk in there as possible. I'm fine teaching it to load multiple binary formats, and it will certainly have a boot picker menu and config file, like any other simple linux/OS loader
<kettenis>
but no device drivers yet, so you don't get to run a shell
<j`ey>
Bluerise: but is there a repo containing a)?
<marcan>
how does the openbsd loader interface with firmware to load files from disk?
<marcan>
does it require UEFI or can it use a simpler interface?
<j`ey>
marcan: Oh, I thought m1n1 was intending to be a much more temporary thing!
<kettenis>
on armv7 and arm64 it currently uses UEFI
<Bluerise>
which everyone else does as well.
<kettenis>
but it really only needs a sensible interface to access raw disk blocks and send/receive network packets
<marcan>
j`ey: the final direction isn't set yet, but for example, we could wind up with m1n1 embedding u-boot as a built-in second stage, if it makes sense; but OTOH u-boot is mostly an embedded device bootloader, not a boot picker AFAIK
<marcan>
so it's not exactly that useful for linux
<kettenis>
(whether UEFI can be called a sensible interface is debatable)
<marcan>
kettenis: well linux can be booted by just putting a kernel and a ramdisk in ram :)
<marcan>
e.g. no UEFI on android arm64
<marcan>
nor on raspberry pi
<marcan>
so how does openbsd work on the rpi?
<Bluerise>
UEFI EDK2
<marcan>
heh
<kettenis>
you can either use u-boot or the EDK2 on the rpi
<kettenis>
loading the OpenBSD kernel in RAM and exuting it works as well
<kettenis>
that's what I'm currently doing
<marcan>
so the thing about m1n1 is it'll handle CPU init and making a sane linux devicetree, which AIUI u-boot can also use?
<marcan>
if the openbsd kernel can be loaded like a linux kernel and booted directly, then doing that directly from m1n1 would probably be the least-effort path
<kettenis>
yes, so u-boot as a relatively simple payload would work fine
<marcan>
yeah, that too
<marcan>
this isn't uncommon
<marcan>
e.g. I think the boot chain for the google pixel c has like 4 stages
<kettenis>
so what we really want on OpenBSD is to have as much the same boot flow as possible across architectures
<kettenis>
some essential bits in that picture are:
<kettenis>
1. bootloader reads some entropy from a file in an UFS filesystem and passes that to the kernel in a special ELF segment
<kettenis>
2. the kernel gets loaded from an UFS filesystem such that you can simply copy it into /. and reboot
<marcan>
arch linux arm does something like that, but the kernel can be in /boot (e.g. on the rpi), which means I can just make that FAT32 and not have to have a full ext4/whatever driver in m1n1
<marcan>
there isn't a terribly good reason to use a fancy filesystem for the boot partition, e.g. this setup is one fairly common option on PCs (making /boot the ESP)
<marcan>
(I use it on a few machines)
<marcan>
does openbsd support devicetrees?
<kettenis>
yup
<marcan>
how does that fit in with UEFI - one or the other?
<kettenis>
UEFI has support for device trees
<marcan>
ah, heh
<marcan>
(I've never used UEFI on ARM)
<marcan>
how much of the UEFI API does it need? e.g. if all I need are protocol stubs for disk I/O (read/write sector) and console write (for text output to the framebuffer) then that could conceivably be added to m1n1
<kettenis>
ARM (the company) keeps pushing ACPI and some of the newer server systems only support that
<marcan>
but I certainly don't want to go down the path of deep hardware info stuff, ACPI, etc
<Bluerise>
there's no need for ACPI
<marcan>
yeah, ARM also keeps pushing PSCI and there will never be PSCI on M1
<marcan>
so we're already diverging there by necessity
<marcan>
:)
<kettenis>
PSCI isn't a bad idea
<marcan>
PSCI needs trustzone, which does not exist on M1
<marcan>
so good luck with that
<marcan>
there is no EL3
<kettenis>
PSCI doesn't really require trustzone
<marcan>
aren't PSCI calls monitor calls?
<kettenis>
yes, but you can choose between smc and hvc
<marcan>
heh, didn't know hvc was an option
<marcan>
in that case it could be done, but then you lose virtualization support
<marcan>
which is also not something I want to lose
<kettenis>
downside of course is that then your kernel would run in EL1 instead of EL2 which means you lose virtualisation
<kettenis>
heh
<kettenis>
anyway, PSCI isn't essential for OpenBSD
<kettenis>
and I don't think Linux cares as much either
<marcan>
can you do the same spintable thing Linux supports?
<marcan>
that's the other option Linux has
<marcan>
and what we will use a priori
<marcan>
(I'm going to write support for that in the next day or two)
<kettenis>
yes, cause the rpi doesn't have PSCI either if you use u-boot ;)
<marcan>
:)
<kettenis>
full-disclosure, I'm currently using corelliums preloader-m1 to load the kernel
<marcan>
yeah, no offense but I'm not touching that thing
<marcan>
in that case it looks like for testing you could and probably should get away with loading openbsd kernels into m1n1, even via serial like I do for linux for development
<kettenis>
but I'm interested in seeing what I can do with m1n1
<marcan>
and then for production, decide on how you want to hook up the support for loading kernels the normal way
<marcan>
either by making m1n1 do enough of UEFI for you guys, if it's really a minimal part; or by chaining u-boot and teaching it about disk I/O
<marcan>
how does openbsd get loaded in the u-boot path?
<marcan>
just UEFI?
<kettenis>
just UEFI
<marcan>
fair
<kettenis>
we adopted the stuff that agraf did really early on
<marcan>
also, if there is a simple enough read-only UFS2/etc implementation I can drop into m1n1 that's fine too
<kettenis>
so it really needs a minimal set
<marcan>
I'm not opposed to adding FS support as long as it's not NTFS levels of junk
<marcan>
as long as the licensing is not a problem
<marcan>
the only reason I like FAT32 is that elm-chan fatfs is just so damn easy to use and works everywhere
<kettenis>
we have our own ufs/ufs2 implementation in the shared bootloader code
<kettenis>
so we only really need raw disk access
<kettenis>
note that the BSDs have their own cross-architecture "partition table" called disklabel
<marcan>
obviously that's not going to fly on M1
<marcan>
apple requires GPT and APFS volumes to boot from
<marcan>
so if you want disklabels, they'll have to be inside a GPT partition
<marcan>
in there you can do whatever you want
<kettenis>
yes, disklabels can live in a GPT partition
<marcan>
no problem then
<kettenis>
anyway, these are not really details you need to care about
<kettenis>
but another reason why we really need raw disk access instead of filesystem access
<marcan>
sure
<j`ey>
kettenis: OpenBSD runs/can run at EL2?
<marcan>
once I have the disk I/O code in here we can revisit, but basically if there is a way I can load your bootloader and give you hooks to get disk I/O - be it via UEFI or some bespoke mechanism - without it being too much useless overhead, that works perfectly fine for me
<kettenis>
j'ey: it'll drop down to EL1; no virtualization support yet
<marcan>
m1n1 is relocatable and basically standalone, so I don't see why you couldn't just call into its disk I/O as long as you have some sort of sane stack going on
<j`ey>
kettenis: ah
<marcan>
and actually I think at least a portion of m1n1 needs to stay in RAM after OS boot anyway, to handle resume from sleep scenarios, though that part isn't clear yet
<marcan>
has to do with CPU init chicken bits and the resume vector being locked down
<marcan>
though obviously that does not include the FS code
<marcan>
but to a first approximation we could leave all of m1n1 in reserved RAM, it's not like it's big anyway
<kettenis>
anyway, I'll look at using u-boot as a payload
<marcan>
well right now u-boot can't talk to the disk anyway, so not sure how much benefit that would be other than for fun :)
<marcan>
also depends on the spintable thing, whether u-boot can chain from that to the next stage or whether it reimplements it and thus needs its own CPU init code
<marcan>
I haven't looked into any of this in u-boot yet
<kettenis>
u-boot doesn't spin up the other CPUs
<agraf>
Bluerise: sorry, was asleep until just now :)
<marcan>
ah, so it just passes spintable info from the devicetree it gets?
<agraf>
Bluerise: I think porting U-Boot is an amazing idea
<marcan>
in that case that would work fine in principle
<kettenis>
it would just leave them spinning, so as long as it doesn't toch the memory where they're spinning it should be fine
<marcan>
yeah
<agraf>
Bluerise: It also solves the update problem nicely. The current Corellium blobs require you to go into recovery mode on update, because the kernel checksum is stored in the firmware
<kettenis>
things get interesting for suspend/resume of course as you say
<marcan>
wonder how much porting it really needs then... probably just the same stuff I did for linux, IRQs and the FIQ timer thing, a patch or two to serial or maybe not even that, and that's about it
<marcan>
plus the disk I/O
<kettenis>
I think u-boot only uses polled I/O
<agraf>
yes, and a bit of startup code
<agraf>
IRQs are optional
<marcan>
agraf: m1n1 will solve that anyway, as I said I'm adding disk support :p
<agraf>
exactly :)
<marcan>
the corellium preloader stuff is a terrible idea
<agraf>
marcan: why reinvent the wheel?
<marcan>
m1n1 was never intended to go that way
<marcan>
agraf: because it's easy
<agraf>
Haha :)
<marcan>
we need to work out disk I/O anyway, so I'll be writing that code for testing purposes
<marcan>
once you have that, throwing in fatfs and a simple config file parser is stupid easy
<marcan>
and I already did that for asbestos anyway
<agraf>
yeah, and then you have distros that are going to curse at you for the rest of your life because they now have to treat M1 special ;)
<agraf>
if you want to target distros, you want *one* boot protocol, not 50
<marcan>
ALARM already treats every platform as special anyway
<marcan>
:p
<agraf>
That's the whole reason I built the UEFI support in U-Boot
<agraf>
What is ALARM?
<marcan>
arch linux arm
<agraf>
Alpine?
<agraf>
Ah
<marcan>
anyway I'm saying you will be *able* to use m1n1 for this, not that distros won't want to chain u-boot
<marcan>
chaining u-boot was always one path I had in mind :)
<marcan>
we'll see in the long term what ends up being used
<marcan>
so yes, someone should port u-boot anyway
<marcan>
how do those platforms boot anyway, as far as distros go?
<marcan>
do they have tooling to mess with u-boot configs?
<marcan>
or is it EFI style bootXXX.EFI?
<agraf>
No, U-Boot just implements the UEFI removable protocol
<agraf>
yes :)
<marcan>
lol ok
<agraf>
it even implements bootmgr support these days
<agraf>
so in theory you can store an actual boot order
<marcan>
store it where?
<marcan>
some nvram file?
<agraf>
That's implementation dependent
<marcan>
how do you pick kernels?
<marcan>
ala grub
<agraf>
There's a module that does it via OP-TEE, IIRC there's also one that just does it only at boot time via the UEFI env code, so could be anywhere, even on disk
<agraf>
you boot grub
<agraf>
:)
<marcan>
lol
<marcan>
yeah as I said, crazy boot chains on ARM
<agraf>
or the OpenBSD loader for that matter
<marcan>
this is totally going to end up being SecureROM -> iBoot1 -> iBoot2 -> m1n1 -> u-boot -> grub -> linux, isn't it
<agraf>
That wouldn't be too far off from the usual boot chains on ARM, yeah
<agraf>
I'm still not sure why we would need m1n1 in the picture though
<Bluerise>
agraf: heh, that's what I thought as well
<marcan>
anyway, one thing I was going to write was embedded second stage support in m1n1, both for testing self-contained boot a la corellium now (which sucks, but has its uses), and for embedding e.g. u-boot
<marcan>
well, really the point is m1n1 will spin up the CPUs and apply chicken bits
<Bluerise>
agraf: thanks for the EFI support in U-Boot, I'm really happy that we have it :)
<agraf>
Sure, absolutely :)
<marcan>
if u-boot does not do SMP spinup then we need that
<agraf>
Bluerise: I'm super happy it's been useful beyond my own use case ;)
<marcan>
and it might make sense not to pollute u-boot with all that junk
<agraf>
marcan: U-Boot does SMP spinup on some platforms
<agraf>
marcan: There are special per-SoC directories that are basically just dumpsters for exactly that type of code
<agraf>
:)
<marcan>
also, dealing with ADTs and FDTs
<Bluerise>
agraf: it's been a blessing for OpenBSD, and also for $work
<marcan>
I mean if u-boot wants to copy and paste all the m1n1 code for this and make m1n1 unnecessary then sure
<agraf>
Again, it has special hooks for exactly that type of purpose
<kettenis>
turtles all the way down
<marcan>
but does it gain anything from that, vs just wrapping it in m1n1?
<agraf>
Yeah, let's just see what Bluerise comes up with :)
<marcan>
and getting a nice standard devicetree and SMP spintable passed to it?
<Bluerise>
marcan: only one binary to install
<agraf>
I'd be curious to see which way actually ends up easier / more maintainable down the road
<marcan>
Bluerise: m1n1 would embed u-boot as a second stage
<marcan>
(again this is common)
<agraf>
Bluerise: if you embed U-Boot into the m1n1 binary, you only have one binary too
<agraf>
It's more about one source of reference ;)
<Bluerise>
for us u-boot is really nice since it does *everything*. so we have one port for u-boot, which depends on the atf port, and the resulting binaries from the u-boot build is all that's needed to be distributed
<marcan>
no atf here so :)
<agraf>
Bluerise: you could treat m1n1 like ATF, no?
<Bluerise>
agraf: hehe, yes
<agraf>
Bluerise: just do the linking step with m1n1 instead of ATF
<kettenis>
so in this case I would have U-Boot just use the device tree set up by m1n1
<marcan>
fwiw I want to see if iBoot2 will just dump whole macho files in RAM or not
<marcan>
if it does we could literally do cat m1n1.macho u-boot.elf (or whatever format) > boot.macho
<marcan>
not sure yet though
<Bluerise>
agraf: compile u-boot, bundle with m1n1 as atf, boot u-boot which first runs m1n1 and jumps back into u-boot or so?
<marcan>
if not it would need a trivial tool to embed
<agraf>
marcan: You can easily provide a tool to patch the Mach-O header accordingly as part of m1n1 ;)
<kettenis>
@marcan: that is essentially what the corellium guys do in their bootloader
<marcan>
^^
<agraf>
Bluerise: yup
<marcan>
kettenis: yes, but they have a tool
<kettenis>
it isn't a simple cat
<marcan>
actually let me try this right now
<marcan>
actually this won't work
<marcan>
because IIRC iBoot2 puts data after the macho
<marcan>
so yeah, it'd need a little tool
<marcan>
but not a big deal
<marcan>
probably just patching a single number in the macho with the payload size
<marcan>
actually, I wonder if that works as intended, let me try something
<never_released>
agraf: I have a TianoCore port around
<never_released>
why use u-boot even
vimal has quit [Remote host closed the connection]
<never_released>
(targeted at iPhone 7, but can carry it to the Mac if needed)
<kettenis>
tianocore would work as well, but I suspect it isn't as lightweight as u-boot
<Bluerise>
oh that's nice, never_released
<kettenis>
too much complexity for my liking
<Bluerise>
heh.
<never_released>
kettenis: u-boot is just as complex :P
<kettenis>
but if I don't have to figure it out myself I don't care ;)
<j`ey>
never_released: I'd be interested to look at that, if it's online somewhere
<never_released>
and I'm kinda interested in running Windows later on
<never_released>
j`ey: not touched since a year now
<j`ey>
never_released: even so
<Bluerise>
Hm, can u-boot boot windows with the EIF API? shouldn't that work? (not questioning, just wondering)
<never_released>
Bluerise: don't think so
<agraf>
Bluerise: IIRC there were a few things missing for Windows support
<Bluerise>
I know my arm64 workstation can boot windows
<Bluerise>
(HoneyComb LX2K)
<agraf>
Bluerise: that one is using edk2 :)
<Bluerise>
heh, yes
<never_released>
Windows requirements aren't that big
<agraf>
There were a few UEFI protocols that Windows relied on that U-Boot didn't implement last time I looked
<Bluerise>
though lx2k can do both edk2 and u-boot, the windows that booted on lx2k was with edk2
<never_released>
just UEFI + ACPI + GICv2 minimum :P
<never_released>
no FIQ too
<kettenis>
a few challenges there ;)
<never_released>
kettenis: have been thinking about two horrific ways to achieve a Windows boot
<never_released>
first one, getting functional nested virtualisation (because I want the guest to see EL2 too) and have a thin adaptation layer
<never_released>
second one, VMSA lock register, to control VBAR
<never_released>
(and third-one, which is a no-man's-land, GXF)
<marcan>
the m1 does not support nested VM as far as I know
<marcan>
ohh this is *excellent*!
<marcan>
so it turns out
<marcan>
1) iBoot does indeed do proper mach-o loading, and supports noncontiguous segment loads
<marcan>
2) iBoot does not panic if a segment load overlaps the end of the file
<marcan>
3) instead, it helpfully behaves as if the load filesize was truncated to the end of the machofile, and zeroes out the rest of the buffer
<marcan>
that means our payload insertion tool is now officially `cat`
<marcan>
I tested up to a 64MB dummy segment off the end of the file and iBoot is perfectly happy with it (and it does not impact boot times visibly)
<marcan>
so we can have up to a 64MB payload with that, no problem
<marcan>
just cat it on
<marcan>
this also means I can have a lot of fun with payload formats, e.g. embed a command script by cating it on, very very convenient for end users
<marcan>
should be able to have a single binary build that does everything this way
<marcan>
file layout is [m1n1 macho text/rodata/data][payload], memory layout is [firmwares and stuff iBoot puts in RAM][ASLR padding][m1n1 macho text/rodata/data][m1n1 bss][payload..... pad to 64MB][things iBoot passes us, cmdline, adt, etc][free memory.......][framebuffer and maybe other things][top of RAM]
<kettenis>
any way to force alignment of [payload]?
<marcan>
KASLR alignment from iBoot is 64K as far as I can tell, and we can preserve that in the mach-o
<marcan>
maybe 16K? definitely no smaller than that
<marcan>
ah yeah 16K
<marcan>
but m1n1 can copy it out to a more-aligned buffer if we need that for something
<marcan>
as long as whatever file format it is has a length (though since the memory is padded with zeroes, we could heuristically use that too, but we should probably not go there)
<kettenis>
so an ELF header or a linux kernel header would work (could do either for a u-boot payload)
<never_released>
marcan: what I'd do is concatenating the macOS kernelcache
<never_released>
personally
<never_released>
to have a Continue to macOS option
<never_released>
but it might be "why not both?"
<marcan>
kettenis: yup
<marcan>
never_released: well, we need to do that every update anyway, unless we implement APFS support; at that point it makes more sense to just copy the macOS kernelcache to the linux boot partition as part of the install process I think
<marcan>
also I intend to use a different APFS boot structure for linux anyway
<marcan>
not reuse a single macos one
<marcan>
because people will want to be able to do secure macos boot, we should't mix the OSes
<marcan>
I think the only people interested in this should be people who want to mess around with the darwin kernelcache
<never_released>
marcan: when you have FS access
<never_released>
the macOS kernel cache is easily query-able anyway
<marcan>
as long as you can read APFS, yes, but I'm not putting APFS into m1n1 :p
<marcan>
from linux though, sure
<marcan>
so you could copy out updates from there
<never_released>
marcan: I want to use Linux as a bootloader here :P
<marcan>
if you really wanted to do this
<never_released>
think that I said it before
<marcan>
well... that's not the approach I'm interested in but have fun :p
<marcan>
the problem is you're running multiple OSes under one OS context from the firmware's point of view then
<marcan>
which isn't really how things are intended to work
<never_released>
just don't load the FW-dependent stuff
<dhewg>
sounds like ps3 petitloader
<never_released>
not communicating with SEP for example
<marcan>
well yes, but macos does that, and I intend to do that too
<marcan>
because it's useful
<marcan>
I don't want to have to buy typeC yubikeys and have them eat one port on these macs
<never_released>
I mean
<marcan>
when there is a perfectly fine embedded secure element
<never_released>
for a bootloader kernel
<never_released>
not needed
<marcan>
yes but you can't *switch* contexts
<never_released>
you have a Linux build without those
<marcan>
so then whatever you bootload ends up in the same context
<never_released>
marcan: hmmm... but you have to pay the 15GB for each macOS install cost
<never_released>
then
<marcan>
no
<marcan>
I will be doing minimal stub boot partitions without a full macos
<never_released>
marcan: and how will you authentify then?
<never_released>
to demote
<never_released>
remember, your new OS context is at full security
<marcan>
right *now*, you'd have to install macos, make a user, then remove all the garbage and shrink the partition once demoted
<marcan>
however, we can build tooling to avoid that
<never_released>
you think?
<never_released>
it's by design
<marcan>
yes and no
<marcan>
there are APIs for importing user stuff to a new install, or for adopted installs
<marcan>
there's just lots of bugs because apple rushed this all out
<never_released>
you suppose that python exec will stay in macOS Recovery forever
<never_released>
to call those funcs though ctypes
<marcan>
I'm 99% sure we will be able to build good tooling to do this
<never_released>
I think that's going away
<marcan>
I disagree
<marcan>
:)
<never_released>
I wouldn't bet on that :)
<marcan>
and I will
<marcan>
:)
<j`ey>
never_released: why do you think it's going away?
<never_released>
j`ey: macOS Recovery is supposed to be a secure env with code signing enforced
<marcan>
for starters, we could do the install and all this stuff from macos itself, not doing anything from 1TR except calling bputil/kmutil
<never_released>
today, you can copy for example Python from macOS because that's Apple signed
<marcan>
because installing macos from macos is supported
<never_released>
having a hole in the door
<marcan>
never_released: you're making assumptions about apple's security model that don't make sense
<marcan>
1TR lets you run unsigned code on the machine
<marcan>
*after* you authenticate
<marcan>
apple doesn't care what you do in 1TR as long as you assert physical presence and, for OS-impacting operations, provide credentials
<marcan>
to guarantee data security
<never_released>
marcan: 1TR itself is tightly locked down, with an Apple-only CS policy
<marcan>
but you have a root shell
<marcan>
anyway, you can have your opinion and I can have mine :)
<marcan>
we'll see what apple does
<never_released>
yep, and Apple-only CS + can freely run any Apple-signed code at the same time
<never_released>
it's a contradiction by itself
<marcan>
1TR has *perl*
<marcan>
like in 1TR itself
<never_released>
yep
<never_released>
it's a walking set of contradictions
<marcan>
and you're assuming it resolves one way
<marcan>
and I'm betting it resolves another way
<marcan>
only time will tell
<marcan>
:)
<never_released>
I mean, I have a set of bugs to disable AMFI in 1TR
<never_released>
but I'd prefer to not _have_ to use them
<marcan>
we will not be using any bugs
<marcan>
we will be using APIs and features Apple builds
<marcan>
I have several possible plans depending on what they do
<marcan>
to avoid having to have full macos installs
<never_released>
hopefully it matures quickly enough
<never_released>
I also want to run Linux from APFS eventually
<marcan>
but I'm sure our users will appreaciate being able to run iOS apps in macos while they have a separate linux install
<marcan>
so I will not be pushing the shared-context use case
<marcan>
if people want to do that that's up to them
<marcan>
but there are many pitfalls with that approach
<marcan>
not in the least that it's going to break macos updates in some ways
<never_released>
about iOS apps on macOS, did you know that they are decrypted?
<never_released>
lol
<marcan>
and make it impossible for Linux to use the SEP properly
<marcan>
*that* part of Apple's grand plan is obvious
<marcan>
one OS, one bootpolicy, one context, one data encryption setup, one user auth db, etc
<marcan>
so while you can certainly overlap things, that's definitely not how they intend this to be done
flying_sausages has quit [Quit: You just lost the game. Peace Out.]
acelogic2 has quit [Ping timeout: 260 seconds]
flying_sausages has joined #asahi-dev
taziden has quit [Ping timeout: 240 seconds]
taziden has joined #asahi-dev
robinp_ is now known as robinp
JTL has quit [Ping timeout: 264 seconds]
JTL has joined #asahi-dev
<kettenis>
Â/window 1
<kettenis>
oops, sorry
sirn has quit [Ping timeout: 264 seconds]
narmstrong has quit [Ping timeout: 264 seconds]
nkaretnikov has quit [Ping timeout: 265 seconds]
HeN has quit [Ping timeout: 265 seconds]
eric_engestrom has quit [Ping timeout: 272 seconds]
rann has quit [Read error: Connection reset by peer]
sferrini has quit [Read error: Connection reset by peer]
austriancoder has quit [Write error: Connection reset by peer]
jkkm has quit [Read error: Connection reset by peer]
doof has quit [Write error: Connection reset by peer]
WhyNotHugo has quit [Write error: Connection reset by peer]
brinly has quit [Read error: Connection reset by peer]
tardyp has quit [Read error: Connection reset by peer]
jabashque has quit [Read error: Connection reset by peer]
hatf0 has quit [Read error: Connection reset by peer]
titanous_ has quit [Read error: Connection reset by peer]
r1fl has quit [Read error: Connection reset by peer]
NekomimiScience has quit [Read error: Connection reset by peer]
rjeli has quit [Read error: Connection reset by peer]
myfreeweb has quit [Read error: Connection reset by peer]
diddledan has quit [Read error: Connection reset by peer]
robher has quit [Write error: Connection reset by peer]
puhitaku has quit [Read error: Connection reset by peer]
modmuss50 has quit [Read error: Connection reset by peer]
prusnak has quit [Write error: Connection reset by peer]
WhyNotHugo has joined #asahi-dev
myfreeweb has joined #asahi-dev
eric_engestrom has joined #asahi-dev
nkaretnikov has joined #asahi-dev
hatf0 has joined #asahi-dev
rjeli has joined #asahi-dev
brinly has joined #asahi-dev
jabashque has joined #asahi-dev
narmstrong has joined #asahi-dev
sferrini has joined #asahi-dev
modmuss50 has joined #asahi-dev
robher has joined #asahi-dev
diddledan has joined #asahi-dev
NekomimiScience has joined #asahi-dev
puhitaku has joined #asahi-dev
doof has joined #asahi-dev
jkkm has joined #asahi-dev
HeN has joined #asahi-dev
HeN has quit [Ping timeout: 272 seconds]
sirn has joined #asahi-dev
r1fl has joined #asahi-dev
tardyp has joined #asahi-dev
prusnak has joined #asahi-dev
rann has joined #asahi-dev
titanous_ has joined #asahi-dev
titanous_ is now known as titanous
titanous has quit [Changing host]
titanous has joined #asahi-dev
HeN has joined #asahi-dev
titanous has joined #asahi-dev
titanous has quit [Changing host]
austriancoder has joined #asahi-dev
<davidrysk[m]>
marcan: nested virtualization is a base feature of ARMv8.3
acelogic has joined #asahi-dev
<krbtgt>
could also just force a hypervisor above everything even with a single VM
<krbtgt>
that's what IBM HW does
<krbtgt>
even a system without LPARs (IBM for VM) is still running a dom0 and the "bare metal" host as dom1 on top of an HV
<davidrysk[m]>
I can see why shared-context may be appealing to security researchers, but that is not whom Asahi Linux is for, and that's not what upstream caters for either
<marcan>
davidrysk[m]: ID_AA64MMFR2_EL1[NV] == 0
jkkm has quit [Read error: Connection reset by peer]
HeN has quit [Read error: Connection reset by peer]