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
brandas has joined #asahi
<marcan>
never_released: probably because they have bugs that write to bad MMIO or stuff like that :p
<marcan>
anyway, the L2C status registers neatly tell you where nGnRE is allowed and where not
<marcan>
just replying to the mailing list about this, but the valid ranges are
<marcan>
0x400000000 - 0x4ffffffff
<marcan>
0x580000000 - 0x67fffffff
<marcan>
0x6a0000000 - 0x6ffffffff
<marcan>
which is as you'd expect (PCIe)
<kettenis>
interesting, so 1G of mmio space for the TB4 PCIe controllers and 1.5G (512M + 1G) for the "normal" PCIe controller
<marcan>
4G for the TB4 ones
<marcan>
the ranges are different - 512M + 1G for the "normal" PCIe controller, and 2G + 1G + 1G for the TB4 ones
<marcan>
which does kind of make sense given the usage
<marcan>
the TB ones also have more features (piodma?)
<marcan>
presumably one of those 1G windows is the IO space?
<kettenis>
ah, yes, I probably should get some zzz
<kettenis>
managed to get the xhci(4) on the pcie bus to do DMA in u-boot
<marcan>
cool!
<kettenis>
but there is still something wrong as commands from the CPU to the controller time out
<marcan>
I'll allocate some time this week to bringing up the pcie stuff in m1n1, and try it out (and also dwc3).
<marcan>
remind me again, do you have a serial interface?
<kettenis>
not yet
<marcan>
damn, the testing cycle must suck
<marcan>
typing out the 1TR commands by hand too? :)
<kettenis>
Bluerise sent me one but it got stuck in a snowstorm
<marcan>
ah, I see
<kettenis>
I use the curl trick
<marcan>
yeah, but you still need to type curl :)
<marcan>
I automated the whole reboot-enter 1TR-pull up termina-type command thing when I first brought this up, using a keyboard emulator and the reboot USB-PD command
<marcan>
anyway, I'll send you a proper serial adapter too, once those are built, if you want
<kettenis>
heh, that'd be great
<kettenis>
me and a soldering iron don't get along very well
<marcan>
cool, count on one :)
<kettenis>
btw, if you have m1n1 bring up pcie, I can ditch pretty much all of the corellium code I'm now using ;)
<marcan>
yeah, that's the plan :)
<marcan>
modulo pcie, have you tried chaining through m1n1, now that it supports payloads?
<marcan>
still kind of blind though, I need to add an fbcon
<kettenis>
not yet; planning on giving that a go once the serial adapter arrives
<marcan>
cool!
<marcan>
let me know how it goes :)
<kettenis>
anyway, zzz time here
<marcan>
good night!
Raqbit has quit [Quit: Ping timeout (120 seconds)]
Raqbit has joined #asahi
m42uko has quit [Ping timeout: 246 seconds]
m42uko has joined #asahi
bdju has quit [Ping timeout: 276 seconds]
bdju has joined #asahi
raster has quit [Quit: Gettin' stinky!]
phiologe has quit [Ping timeout: 258 seconds]
phiologe has joined #asahi
r1fl has quit [Read error: Connection reset by peer]
austriancoder has quit [Read error: Connection reset by peer]
arnd has quit [Read error: Connection reset by peer]
doof has quit [Read error: Connection reset by peer]
r1fl has joined #asahi
arnd has joined #asahi
austriancoder has joined #asahi
doof has joined #asahi
user1tt[m] has joined #asahi
robinp_ has joined #asahi
marvin24 has quit [Ping timeout: 258 seconds]
m1kr0[m] is now known as zvtu[m]
marvin24 has joined #asahi
robinp has quit [Ping timeout: 264 seconds]
acelogic has quit [Ping timeout: 256 seconds]
odmir_ has quit [Remote host closed the connection]
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
_whitelogger has joined #asahi
jaXvi has quit [Ping timeout: 265 seconds]
jaXvi has joined #asahi
BaughnLogBot has quit [Ping timeout: 240 seconds]
BaughnLogBot has joined #asahi
acelogic has joined #asahi
VinDuv has joined #asahi
mndza has joined #asahi
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
TheJollyRoger has quit [Remote host closed the connection]
TheJollyRoger has joined #asahi
Necrosporus has joined #asahi
VinDuv has quit [Quit: Leaving.]
acelogic has quit [Ping timeout: 272 seconds]
cdesai has quit [Remote host closed the connection]
cdesai has joined #asahi
klaus has joined #asahi
bdju has quit [Quit: Reconnecting]
bdju has joined #asahi
amw has quit [Ping timeout: 256 seconds]
Foxboron has quit [Ping timeout: 265 seconds]
<Necrosporus>
I'm wondering why marcan 's bootlogs look like failed initrd init (dropping to busybox). Did you reproduce the results of other team who put a full desktop in place yet?
<dottedmag>
Because that's what's initrd he uses contains: a shell.
cdesai has quit [Remote host closed the connection]
cdesai has joined #asahi
<Necrosporus>
Yeah, of course. I was wondering why there is no bootlog from a full-fledged distro
l0bara has quit []
vimal has quit [Remote host closed the connection]
<Glanzmann>
Necrosporus: I reproduced building m1n1 and boot a kernel, but I miss the serial cable, so I could not use the bash. Also my initrd did not work.
<Glanzmann>
Necrosporus: corelliumhq has more drivers as of now but hopefully we get more drivers soon.
<Necrosporus>
Glanzmann, well, perhaps you can use another M1 machine for serial
<j`ey>
Necrosporus: there's no bootlog from a distro, cos theres no distro!
<Glanzmann>
j`ey: But with the corelliumhq you can already have an almost usable desktop. Just sound, GPU and palm detection is missing.
<Necrosporus>
did anybody post a serial bootlog of unmodified macOS on M1 yet (except changing nvram to enable verbose boot)?
<Glanzmann>
But I tried the CPU is fast enough to render a 4K 60 FPS video in software.
<j`ey>
Glanzmann: right, just saying what marc-an did
<marcan>
never_released: my initramfs contains *only* busybox
<marcan>
er, Necrosporus
<marcan>
Glanzmann: corellium are porting drivers from their secret kernel that they've been developing for a year+ without publishing it
<marcan>
I'm trying to put together something upstreamable, which means going slowly
<marcan>
their first demo just had what I have right now, plus USB, then they stuck a USB flash drive/keyboard/mouse/ethernet adaptor in there and presto, "fully usable distro"
<Necrosporus>
Though it doesn't look good when you need to plug external ethernet while having internal one
<marcan>
they have pcie now, so I assume internal works now
<marcan>
if you actually look at what they've been working on though, it's all easy drivers :-)
<Necrosporus>
Is it generic eth on mac?
<marcan>
it's some broadcom chip
<marcan>
linux should have a driver already
<Necrosporus>
They could have tried to use their silicon for that too
<Necrosporus>
I'm wondering, is Apple cool enough to make a device using only their own chips/components?
<marcan>
that's not really practical
<Necrosporus>
But it has bragging point
<marcan>
bragging is not how companies are run
<Necrosporus>
Depending which companies.
<marcan>
okay, corellium might ;)
<marcan>
apple doesn't work like that though
<Necrosporus>
Though you are right, of course, but Apple is relying on bragging a lot too
<j`ey>
it would be a lot of effort, and what would be the benefit?
<marcan>
they roll their own stuff when nobody else does it well
<Necrosporus>
Like "We have the fastest CPU in the world"
<Necrosporus>
But it actually isn't
<marcan>
that's just marketing, every company does that
<marcan>
"fastest phone"
<marcan>
"biggest phone"
<marcan>
etc
<Necrosporus>
Hm... duck tape a phone to a space rocket
<Necrosporus>
That'll be fastest phone
<marcan>
just hire elon musk
<Necrosporus>
How does M1 in mini perform compared to whatever chip is in high end latest iphone/ipad?
Bublik has quit [Ping timeout: 272 seconds]
<bkero>
lol
vimal has joined #asahi
<marcan>
they use the same cores
Bublik has joined #asahi
<Necrosporus>
Also interesting question, is it possible to take iOS from iPhone and put it on M1, theoretically? I mean it will perhaps be illegal, and most likely hard, given the source isn't available
<marcan>
so presumably, pretty similar per core, per clock
<marcan>
you do realize iOS apps already run on the M1 under macOS, right?
<marcan>
:-)
<marcan>
iOS is just macOS with different frameworks
<marcan>
iOS *already* runs on M1 for most intents and purposes, officially
<bkero>
How different is that from the A78 reference design?
<marcan>
bkero: ?
<Necrosporus>
But should be easier than reverse, given M1 allows to run arbitrary kernel
<bkero>
It's all ARM license derivative, yes?
<marcan>
no
<marcan>
apple's cores are not ARM
<marcan>
they have nothing to do with ARM cores
<bkero>
So they're not licensing the architecture from ARM?
<marcan>
they're licensing the *architecture*. they are not licensing the *microarchitecture*.
<Necrosporus>
marcan, maybe you want to run iOS as it is to test stuff, or like duck tape miniM1 to a sensor display and get a makeshift iPad
<marcan>
that means it just runs the same instructions
<marcan>
(mostly, they broke the spec in several ways)
<bkero>
They're not licensing the ASIC layout? Are you sure?
<marcan>
no
<marcan>
yes
<marcan>
100%
<bkero>
Well, the base ASIC layout that they then modify
<marcan>
no
<marcan>
it's custom
<marcan>
they hired a whole silicon design team for this
<Necrosporus>
They use ARM ISA but not ARM design
<bkero>
That's hard to believe, even with a whole silicon design team.
<marcan>
that is a fact
<Necrosporus>
But why they can't have their own ISA?
bgb has joined #asahi
<marcan>
because that would not be compatible with ARM
<Necrosporus>
Yeah, but... why is it important?
<Necrosporus>
iPhone didn't even have to run on ARM
<marcan>
because otherwise old apps won't run
<marcan>
iPhone started on ARM
<marcan>
Apple didn't start doing their own silicon until later
<marcan>
the original iPhone ran on a Samsung chip
<marcan>
an Exynos if you will
<Necrosporus>
Well, yeah, it's easier to use their existing design in new role then make a new one from scratch
<Necrosporus>
I still have a chromebook with Exynos
<JTL>
Necrosporus: On a related note. I wonder how differnt the iOS "runtime" on M1 is from the iOS userland running on iPhone
<marcan>
they do license silicon IP from other companies - peripherals from DesignWare and such, and possibly also bits of things from ARM like AHB/AXI/etc, things tightly associated with the foundry like fuse cells, etc
<bkero>
and TrustZone
<marcan>
no, they only use a tiny bit of TrustZone
<bkero>
and Imagination
<marcan>
Apple cores do not implement EL3
<marcan>
and they only license patents from Imagination
<marcan>
not designs
<marcan>
otherwise they wouldn't have tried to stop doing that and then had the lawyers fight over it
<marcan>
that would never fly if they were still using Imagination silicon IP
<bkero>
Uh
<bkero>
Weren't they using PowerVR for a long time?
<marcan>
so for all intents and purposes they license from Imagination as much as they license from ARM: patents
<marcan>
yes, but not any more
<marcan>
the GPU is also custom now
<marcan>
the ISA is completely different from Imagination from what I understand
<marcan>
Imagination just has a pile of patents on stuff like TBDR and specific they want to keep to remain compatible, like some Imagination-specific formats
<marcan>
so they keep paying them for that
<bkero>
The layout between those architectures is fairly similar from what I understand. Accelerated tile-based blitting.
<marcan>
yes, hence, patents
<marcan>
not silicon IP
<marcan>
tile-based deferred rendering
<Necrosporus>
Regarding ISA, does it make difference, whenever it's ARM, MIPS, RISC-V, SH4 or whatever? Or the CPUs are going to perform about the same, given they got equally qualified team of designers?
<marcan>
the ISA matters, ask Intel and AMD why the M1 just beat them at performance per watt and is a wider execution pipeline than any x86 ever made
<bkero>
Ask anybody who's ever re-compiled any ARM binary with NEON support
<marcan>
(hint: it's because x86 is exponentially difficult to decode in parallel)
<Necrosporus>
How about non-x86 ISAs?
<marcan>
nobody uses anything else
<marcan>
there are very good reasons to stick to popular ISAs
<Necrosporus>
ARM, MIPS, SPARC, RISC-V, SH4
<marcan>
and with the entire Android world running on ARM, it would be somewhat silly to switch to something else
<maz>
from ARM, they licence the architecture, not patents.
<marcan>
maz: the reason they have to do that is the architecture is patented
<marcan>
:)
<marcan>
that's the form of IP protection architectures have
<Necrosporus>
But suppose some really big corporation wanted to release the best possible CPU, disregarding compatibility concerns altogether.
<bkero>
Also why we need defensive patent pools around RISC-V. Ignoring the patent system doesn't work out well.
<maz>
marcan: sure, just wanted to be precise.
<Necrosporus>
Would ARM be the best ISA out of existing ones?
<bkero>
Necrosporus: Intel and ARM are both leaking rumors about using their chip layouts with an ARM ISA
<marcan>
ARM is pretty good
<j`ey>
bkero: *AMD?
<marcan>
I'm not sure if it's the best, but it's pretty good
<Necrosporus>
better than MIPS?
<bkero>
Sorry, AMD, yes
<marcan>
it's more modern than MIPS, so almost certainly yes
<marcan>
(arm64 I mean)
<bkero>
Best in terms of performance, not openness.
<Necrosporus>
There is MIPS64, isn't it?
<marcan>
yes, but it's much older
<arnd>
arm64 is basically an improved version of mips64
<marcan>
the PS2 was MIPS64
<Necrosporus>
Hm... OK, what other 64-bit ISAs we have besides those three?
<arnd>
it's much closer to that than to arm32 (unlike mips32 vs mips64, which are very similar)
<marcan>
that's a game console released in 2000
<bkero>
Itanium
<bkero>
Various incarnations of PPC
<bkero>
cell if you consider that different than PPC
<arnd>
riscv64 is in the same closely related family as mips64 and arm64, all based on the same lessons learned
<marcan>
cell's PPEs are just xbox PPC cores with some stuff ripped out :)
<marcan>
(the microsoft-proprietary SIMD)
<marcan>
opinions on riscv... vary
<arnd>
sparc, power, parisc, alpha and many others are in the wider risc family but not as close to the mips64/arm64/riscv64 set
<marcan>
as to whether it's really on the same level as arm of design or not
<marcan>
I get the feeling it's been rushed quite a bit
<bkero>
It has the potential to be
<bkero>
without ARM's 10% fee on your sale price
<bkero>
Good enough for disk controllers
<marcan>
it's good enough for a lot of things
<marcan>
but that's not the same as "as good as ARM"
<marcan>
it's unclear what the long-term results will be, we shall see
<marcan>
it'll certainly be great to steal a lot of ARM's thunder in the microcontroller/deep-embedded market
<marcan>
especially since chinese companies will jump on it, so will everyone else who just wants a random side core (like nvidia did)
<arnd>
fro the most part, I'd say risc-v is just lacking the software ecosystem that arm has, but that is a matter of time
<marcan>
but could risc-v compete with, say, the M1 in that class? I wouldn't make that assumption. maybe yes, maybe no.
<bkero>
I do fear that riscv isn't keeping up with standardizing the platform between vendors as well as Linaro did for ARM.
<bkero>
But maybe ARM platform requirements did all the hard work of implementing devicetree
<kettenis>
the hard work was done for powerpc
<marcan>
arm32 predated devicetrees by a bunch, didn't it? that era was hell, with the board init code
<marcan>
openfirmware is where all that started
<bkero>
It did
<marcan>
not sure exactly around when arm32 started adopting dt in linux
<kettenis>
and sun before that
<bkero>
devicetree was meant to heal that fragmentation
<arnd>
marcan: if apple were to change the base isa from arm to riscv, my guess would be that it wouldn't perform all that differently. better in some areas (mainly code density), worse in some areas, and not competitive for anything that doesn't have a ratified extension yet
<arnd>
marcan: we started using dt in linux-3.0
<marcan>
woah, later than I thought
<bkero>
better for Apple's bottom line: no 10% fee to ARM
<arnd>
mid-2011, after a few years of debate
<bkero>
(or whatever % they negotiated)
<marcan>
wait really?
<marcan>
when did I port linux to the starlet? that was DT already
<marcan>
*looks*
<marcan>
oh, that was 2015. I guess it was that let when I got bored.
<marcan>
*late
<never_released>
marcan: yes, when device tree came to Linux
<never_released>
for arm systems, Windows devices with UEFI + ACPI on Arm were shipping since ages
<arnd>
powerpc had been converted to dt-only a few years earlier, and when Linaro formed we assumed we could easily do the same thing on Arm. It turned out that going from three SoC vendors to 70 SoC vendors and from a simple networking SoC to a Cortex-A9 class mobile phone SoC made it somehwat harder
<bkero>
with custom UEFI executables including ntldr
<bkero>
for almost each platform
<marcan>
Open Firmware existed since, what, 1994?
<never_released>
Windows RT was shipping in 2012, with support for TI, NVIDIA and Qualcomm SoCs
<never_released>
if it wasn't locked down out of the box...
<never_released>
I ended up releasing a Secure Boot bug for unlocking those in 2016
<never_released>
which was a bit too late :)
<bkero>
Probably useful with a gimpy Surface RT
<bkero>
*for someone with a
<never_released>
bkero: what's annoying is that linux does *not* support ACPI for 32-bit arm
<arnd>
DEC Shark with StrongARM110 shipped with Open Firmware in the 1990s, but is equally irrelevant as Windows RT
<bkero>
never_released: Linux has a hard time supporting ACPI at all. Then again ACPI was meant to be portable but wasn't really implemented that way by vendors.
<never_released>
it's a nicer option than device tree though
<marcan>
ACPI is a joke; one of my first Linux patches was a workaround for broken ACPI tables in my laptop at the time
<bkero>
I've decompiled my ACPI program and seen how many times it checks for Windows strings for its functionality. It's...disappointing.
<marcan>
nobody implements it properly
<kettenis>
the acpi standard is hopelessly ambiguous
<never_released>
marcan: and device tree isn't stable like it should be, so you can't really ship it in firmware
<marcan>
also Linux broke the ACPI backlight method on the iMac I'm typing this on at some point... and I wouldn't be surprised if it's the firmware's fault
<marcan>
I should bisect that at some point
<never_released>
like... fields still change the whole time
<marcan>
somewhere between 5.6 and 5.9 it broke
<never_released>
in an incompatible way
<diddledan>
I seem to recall reading that Linux often (always?) tells the ACPI code that it's actually Windows because the special cases for !Windows are never tested
<never_released>
I reboot w/ a new kernel to find broken Ethernet
<bkero>
diddledan: can confirm
<diddledan>
by the vendors*
<never_released>
then have to reflash a newer DTB
<marcan>
it does
<never_released>
almost reliably so
<bkero>
except that my Thinkpad actually checks for Linux too...which is odd since no Linux distro actually does that.
<kettenis>
we have our own aml interpreter in OpenBSD and I'm seeing issues all the time where AML makes assumptions that aren't justified by the language in the standard
<bkero>
No clue what that ACPI code does
<never_released>
bkero: on arm, think that everyone in Linux land just reports acpi_osi=Linux
<never_released>
on x86, yeah... Linux pretends to be windows
<arnd>
never_released: you can totally ship a dtb in firmware and we will make sure it stays as stable as ACPI. We do suffer from incompatible changes in DT, but I would definitely reject a patch that breaks a shipping system that used to work
<bkero>
never_released: I don't know if I have any ARM boards that actually implement ACPI.
<arnd>
bkero: you can't support arbitrary board with ACPI because there are no driver bindings
<never_released>
bkero: I have three such systems, but one of which ACPI support is provided as experimental
<never_released>
by the manufacturer
<bkero>
arnd: some boards attempt to support it
<never_released>
^
<never_released>
SystemReady SR requires ACPI only
<arnd>
the way it works on PCs is that you end up device drivers that have a table looking up the machine name to find what the settings should be
<diddledan>
caveat: I am a noob with low level stuff.. with that said, I have never understood the reasoning for choosing acpi vs dt and vice versa
<arnd>
which is arguably worse than what we had before DT
<never_released>
bkero: basically the rules for SystemReady ES are: you can ship just ACPI or DT, not both.
<never_released>
so if you want Windows to ever run
<never_released>
not a choice.
<bkero>
I don't run non-free software so that's not been something I would care to deal with.
<arnd>
and of course, on a PC, you only really have on platform to worry about
<never_released>
bkero: lots of people care
<never_released>
same for VMWare ESXi
<never_released>
don't have ACPI? it won't run
<bkero>
or you fake out the ACPI calls
<never_released>
hmmm? no
<never_released>
it's an unrealistic task
<never_released>
to convert between both
<bkero>
pretty sure Clover does just that
<never_released>
bkero: macOS on x86 just uses ACPI
<never_released>
so no.
<bkero>
pretty sure Clover does just fakes out ACPI calls
<never_released>
it patches some stuff
<never_released>
but it's still ACPI.
<marcan>
diddledan: dt is a lot simpler and more general than ACPI. it's just telling you what hardware you have
<bkero>
I never claimed it wasn't?
<marcan>
ACPI is code
<never_released>
^
<diddledan>
gotcha
<never_released>
and the device names are utterly incompatible between both, you'd need a huge lookup table
<never_released>
among other things
<bkero>
or a text file that you hand the kernel on boot that describes the hardware
<never_released>
hmmm? you want yet another abstraction? bkero
<never_released>
please no
<diddledan>
so DT is "just" a well-defined memory structure that lists everything and then it's up to the OS to talk to the devices without an intermediary (where ACPI might intercept stuff)?
<never_released>
we already have both ACPI and DT, no need for a third
<bkero>
uhh, pretty sure that's how devicetree works
<never_released>
diddledan: DT just describes yet
<never_released>
*yes
<diddledan>
that does sound simpler :-)
<never_released>
whereas ACPI can embed bytecode
<never_released>
notably to implement some platform-independent features or to workaround hardware quirks
<bkero>
or more commonly to implement platform-dependent features
<bkero>
which Linux then has to quirks-patch around
<bkero>
See also: Linux advertising itself as Windows to APCI
<bkero>
ACPI*
<marcan>
ACPI rarely "implements" anything; more commonly it's just a random pile of hacks and throw-at-the-wall copypasta that happen to work on windows because they were tested there
<bkero>
It does implement interfaces to lower-level hardware features unavailable to the general system. Like which sleep states to advertise and trigger.
<marcan>
I was (half) joking
<marcan>
but even that stuff is often more broken than not
* bkero
glares at his Thinkpad which originally didn't support S3 suspend-to-RAM because Microsoft convinced Lenovo that Connected Standby would be the future.
<marcan>
e.g. I have a laptop where the SSD of all things stays warm in sleep mode
<never_released>
bkero: Connected Standby **is** the way ahead
<marcan>
pretty sure that's ACPI's fault
<never_released>
and is what every arm system does anyway
<bkero>
never_released: that's debatable
<never_released>
S0ix does things that I'd expect from a computer
<never_released>
like waking up when there's a phone call
<bkero>
marcan: it's the same thing with the SD card reader on like 4 year's worth of thinkpads.
<never_released>
or a notification
<never_released>
good luck having those with S3
<bkero>
I don't think that's what most people would expect from a computer. Or in many cases even want.
<kettenis>
typical PC ACPI code just triggers an SMI and lets the firmware handle the request in SMM mode
<never_released>
lots of ppl expect that nowadays, imagine having the Skype app open for example, bkero
<never_released>
your laptop has the screen closed
<never_released>
you still want it to ring on a call
<never_released>
like... any phone?
<marcan>
SMM is another problem with ACPI/x86
<marcan>
and one thing I'm very glad does not exist on M1
<bkero>
My laptop also isn't a phone
<marcan>
I actually have a chance at getting decent realtime latencies on these things
<never_released>
bkero: doesn't change that lots of ppl want those features
<bylaws>
<never_released "or a notification"> Android handles this by waking up every minute
<bkero>
never_released: Once again that's just your opinion
<never_released>
and you can't have both S3 and S0ix enabled at the same time
<never_released>
so guess which one gets prioritised
maor26 has joined #asahi
<bylaws>
And waking up every minute massacres all the benefits sleep has
<never_released>
marcan: yeah, Apple removed EL3 on Apple A10 onwards, and didn't bring it back so far
<marcan>
good riddance too
<never_released>
the problem is that PSCI and such are written against systems supporting EL3
<marcan>
it was always a terrible idea for security, and it hurts other things
<marcan>
yeah, that's ARM's fault for pushing TrustZone
<never_released>
you can't be compliant with SystemReady _and_ not implement EL3 at the same time
<marcan>
though I don't really care about EL3 as long as it literally only executes code when called, for PSCI and such
<marcan>
the problem is when vendors throw other junk in there, like they do with SMM
<marcan>
I heard about some Intel system that had >1k SMIs per second to work around bugs in their xHCI controller
<marcan>
it's insane
<kettenis>
dunno, having an open source firmware in EL3 that abstracts some of the platform specifics makes sense to me
<marcan>
if it's open source it's fine
<never_released>
kettenis: "open-source"
<marcan>
the problem is when it's part of the vendorblob
<JTL>
> 10:34 <@marcan> e.g. I have a laptop where the SSD of all things stays warm in sleep mode
<never_released>
not the case for 99.99%
<JTL>
On older MacbookPros that use M.2 with a custom connector, there are reports that non Apple brand SSDs (used with chineseium adapter) cause sleep and reboot issues due to presumably power saving not working "properly"
<never_released>
in the wild
<JTL>
but I digress
<never_released>
and even if it's OSS you can't replace it in most cases
<never_released>
because of systems w/ DRM on
<marcan>
you can't give vendors the power to unilaterally schedule their code or they will abuse it, every time
<never_released>
(w/ part of the DRM implementation being in EL3)
<marcan>
well again that's just part of the ridiculousness of TrustZone
<marcan>
which is a fundamentally broken model anyway
<diddledan>
how's that conversation go? "you broke into our console. now fix it, kthxbai" :-p
<marcan>
checkra1n is just a bootrom exploit
<bkero>
It's non-trivial if you have to desolder and get access to BGA pins, that's true
<never_released>
marcan: and SEPROM :P
<never_released>
SEP is hacked by checkra1n nowadays
<marcan>
bkero: meanwhile on nvidias you just glitch the thing?
<marcan>
that's how the TX1 bootrom was dumped
<JTL>
marcan: From what I gather. Google made a big deal about "wanting" to open source the Titan M firmware in PR posts at Pixel 3 launch, and only crickets came from them for a while, then they annouced the OpenTitan project that *can* run what they consider a "secure HSM/TPM on an FPGA" for prototyping, but I don't know how much it has in common with the Titan M.
* JTL
sigh
<never_released>
yeah X1 wasn't that hardened
<bkero>
marcan: so what's the difference?
<marcan>
the difference is people spent like a decade looking at apple bootroms before finding that bug
<never_released>
not really
<marcan>
while the nvidia bootrom thing was found independently by every team that looked at it in like 30 minutes
<never_released>
has been floating around since a while
<never_released>
before release
<marcan>
never_released: X1 was an unchecked memcpy in the usb stack
<marcan>
it does not get any more stupid than that
<marcan>
that's like literally the first thing you look for
<marcan>
grep for memcpy and stare at the USB stack
<marcan>
checkra1n was a much more subtle thing with confused state
<bkero>
Specifically this was checkm8, not checkra1n
<never_released>
^
<marcan>
checkra1n is the implementation of checkm8
<bkero>
It's just a use-after-free
<marcan>
yes, but getting there requires quite a subtle sequence of operations, it's not obvious
<marcan>
those are much harder to find than memcpy(buf, usb_buf, wLength)
<never_released>
marcan: meanwhile Apple A8 was even more crazy
<never_released>
it did *not* check in the SEPROM if the memory range was locked
<never_released>
so that early AP code exec = you own the SEP too
<never_released>
everyone has their fair share of mistakes there
<marcan>
yeah but apple are trying to push things in the right direction
<marcan>
nvidia... lol
<never_released>
you just saw the X1
<never_released>
lol
<marcan>
we both know about all the custom mitigations in apple's cores
<never_released>
back in that era, their UEFI variable protection mechanism implemented in EL3 was a meme too
<never_released>
but they rewrote that properly for Xavier onwards
<marcan>
I don't know about nvidia's newer stuff
<marcan>
but apple has been on the right path much longer than them
<never_released>
Apple also made their fair share of mistakes
<never_released>
beforehand
<never_released>
you don't get this right the first time
<marcan>
yes, like everyone else, but you can do better or worse at learning
<bkero>
It seems kind of funny to say Apple was on the right path considering they didn't implement secureboot for how long?
<marcan>
e.g. Microsoft got it all hilariously wrong with the xbox original, then they learned *fast* with 360
<marcan>
and even better with the xbone
<bkero>
and then their secureboot key got leaked
<never_released>
bkero: Secure Boot _policy_
<never_released>
and then MS didn't check in DBX that the policies were revoked or not
<never_released>
the way that it was worked around afterwards was quite ingenious
<never_released>
but didn't work everywhere/did actually brick some systems
<marcan>
note that I am *specifically* talking about MS's xbox division here, and the recent Pluton stuff
<never_released>
CurrentPolicy has to become an authenticated variable
<marcan>
I make no claims of MS's security in other fields
<never_released>
w/ a new variable for Secure Boot policies
<never_released>
Xbox Scorpio onwards also switched away from custom to UEFI
<never_released>
for boot firmware
<marcan>
they don't start off in UEFI
<never_released>
marcan: was switched to UEFI
<never_released>
on Scorpio
<never_released>
not OG xbone
<marcan>
I highly doubt they regressed to plain old vanilla UEFI boot
<marcan>
they have custom security cores for a reason
<never_released>
it's a customised UEFI yes
<never_released>
but still UEFI
<never_released>
on xbox one, was fully custom without UEFI in the boot chain at all
<bkero>
What UEFI isn't customized?
<marcan>
it doesn't matter if there is UEFI in the boot chain
<marcan>
what matters is how the secureboot stuff is implemented, and what the attack surfaces are
<never_released>
it's an UEFI FW with an oddball XboxPkg inside
<never_released>
and a custom Secure Boot implementation of course instead of relying on UEFI SB
<marcan>
if the thing still boots off of a side core running not-UEFI security firmware then the UEFI bits are irrelevant here
<never_released>
marcan: like BPMP? or AMD PSP? or?
<marcan>
like BPMP except actually secure
<marcan>
:P
<never_released>
BPMP is much better off nowadays, a security review happened in the meantime :P (but ofc, Tegra X1+ isn't exactly the most secure SoC ever)
<marcan>
a security review happened, too late :)
<marcan>
and you don't change company culture around this this fast
<marcan>
apple has been hiring serious security people for a while now, and actually listens to them
<never_released>
not all of them I can guarantee you
<marcan>
enough
<marcan>
more than nvidia ;)
<never_released>
otherwise iBoot would have been decrypted since ages
<never_released>
battle still ongoing, they're tone deaf on some things
<marcan>
obscurity does not imply lack of security
<never_released>
obscurity also doesn't help
<marcan>
but I *guarantee* nobody competent audited the X1 ROM, because anyone competent would've found *that* thing
<never_released>
because so far
<marcan>
obscurity always helps
<never_released>
any iBoot release ever built for A7-A13 is decrypted
<marcan>
it's why X1 took months to break, instead of 30 minutes
<marcan>
you certainly shouldn't rely on it, but it absolutely helps
sirn has quit [Read error: Connection reset by peer]
sirn has joined #asahi
bgb has quit [Ping timeout: 240 seconds]
ephe_meral has joined #asahi
ephe_meral has quit [Client Quit]
ephe_meral has joined #asahi
bgb has joined #asahi
r1fl has quit [Read error: Connection reset by peer]
r1fl has joined #asahi
bgb has quit [Ping timeout: 240 seconds]
amw has joined #asahi
raster has quit [Remote host closed the connection]
thestr4ng3r has quit [Ping timeout: 264 seconds]
raster has joined #asahi
amw has quit [Ping timeout: 265 seconds]
thestr4ng3r has joined #asahi
bgb has joined #asahi
Bublik has quit [Quit: Bublik]
Bublik has joined #asahi
Bublik has quit [Quit: Bublik]
bgb has quit [Ping timeout: 240 seconds]
bgb has joined #asahi
<davidrysk[m]>
How were the post-checkm8 iBoot releases decrypted? Private vulns?
<marshmallow>
davidrysk[m]: blackbird?
bgb has quit [Ping timeout: 240 seconds]
MoxZ_ has joined #asahi
choozy has joined #asahi
bgb has joined #asahi
bgb has quit [Ping timeout: 258 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 265 seconds]
bgb has joined #asahi
bgb has quit [Ping timeout: 264 seconds]
bgb has joined #asahi
ephe_meral has quit [Ping timeout: 240 seconds]
<never_released>
davidrysk[m]: yes
ephe_meral has joined #asahi
bgb has quit [Ping timeout: 264 seconds]
ephe_meral has quit [Ping timeout: 256 seconds]
ephe_meral has joined #asahi
ephe_meral has quit [Quit: WeeChat 2.9]
ephe_meral has joined #asahi
bgb has joined #asahi
bgb has quit [Ping timeout: 240 seconds]
vimal has quit [Quit: Leaving]
odmir has joined #asahi
vimal has joined #asahi
bgb has joined #asahi
bgb has quit [Ping timeout: 265 seconds]
choozy has quit [Ping timeout: 258 seconds]
bgb has joined #asahi
<modwizcode>
marcan: wait you ported linux to the starlet? why lmao, you didn't publish it anywhere I saw? (I dove way too far into the wii stuff and now it's just sitting around waiting for a blog post)
<modwizcode>
Speaking of firmwares, I think that I started liking risc-v a lot less when they decided to push a bunch of stuff to the SBI, which seemed kind of not great