ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
maxzor_ has quit [Ping timeout: 480 seconds]
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
jolan has joined #dri-devel
Company has quit [Quit: Leaving]
ybogdano has quit [Ping timeout: 480 seconds]
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #dri-devel
q4a1 has quit []
YuGiOhJCJ has joined #dri-devel
rmckeever has joined #dri-devel
caef^ has quit [Ping timeout: 480 seconds]
caef^ has joined #dri-devel
wens_ has left #dri-devel [#dri-devel]
wens has joined #dri-devel
caef^ has quit [Ping timeout: 480 seconds]
caef^ has joined #dri-devel
agd5f has quit [Remote host closed the connection]
Daanct12 has joined #dri-devel
rsalvaterra has quit [Quit: No Ping reply in 180 seconds.]
rsalvaterra has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest290
rsalvaterra_ is now known as rsalvaterra
Guest291 has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
cphealy has quit [Remote host closed the connection]
cphealy has joined #dri-devel
warpme_____ has quit []
aravind has joined #dri-devel
kts has joined #dri-devel
Duke`` has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Duke`` has quit []
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
garrison has joined #dri-devel
garrison has quit []
garrison has joined #dri-devel
garrison has quit []
garrison has joined #dri-devel
garrison has quit []
srslypascal has quit [Remote host closed the connection]
i-garrison has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
srslypascal has joined #dri-devel
Daanct12 has quit [Quit: Leaving]
i-garrison has joined #dri-devel
dcz_ has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
fab has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
rahul_janga has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest323
srslypascal has joined #dri-devel
Guest323 has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
rahul_janga has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
luc4 has joined #dri-devel
JohnnyonFlame has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
djbw has quit [Read error: Connection reset by peer]
rmckeever has quit [Quit: Leaving]
bgs has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
xroumegue has joined #dri-devel
Haaninjo has joined #dri-devel
Duke`` has joined #dri-devel
gouchi has joined #dri-devel
<dcz_> is eglMakeCurrent per-display? when I create 2 displays and make each of them current, it works OK on Intel
<dcz_> but on etnaviv, the kernel goes topsy-turvy
hasebastian[m] has quit []
<emersion> dcz_: I don't think it's per-display
<emersion> there is global implicit state all over the place
<dcz_> that would mean that Intel is going out of my way to prevent me from getting in trouble
<dcz_> *out of their way
<dcz_> thanks. I wish there was some way to communicate the error though. I just wasted a month
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
leo60228 has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
MajorBiscuit has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #dri-devel
rahul_janga has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
leo60228 has joined #dri-devel
kts has quit [Quit: Leaving]
mattst88 has quit [Ping timeout: 480 seconds]
rahul_janga has quit []
Jeremy_Rand_Talos has joined #dri-devel
maxzor has joined #dri-devel
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
kts has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
alatiera0 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
rahul_janga has joined #dri-devel
alatiera08 has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
vyivel has quit [Remote host closed the connection]
alatiera0 has quit [Ping timeout: 480 seconds]
alatiera088 has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
alatiera08 has quit [Ping timeout: 480 seconds]
alatiera08 has joined #dri-devel
alatiera088 has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
alatiera08 is now known as alatiera
<dcz_> I present a motion to dismiss implicit global state entirely. Down with eglMakeCurrent
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
vyivel has quit [Remote host closed the connection]
luc4 has quit []
vyivel has joined #dri-devel
cphealy has quit []
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
fab has joined #dri-devel
cphealy has joined #dri-devel
rahul_janga has quit [Ping timeout: 480 seconds]
rahul_janga has joined #dri-devel
kts has joined #dri-devel
rahul_janga has quit [Ping timeout: 480 seconds]
warpme_____ has joined #dri-devel
rahul_janga has joined #dri-devel
heat has joined #dri-devel
flto has joined #dri-devel
rahul_janga has quit [Read error: Connection reset by peer]
fab has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: leaving]
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
Haaninjo has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
maxzor has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
djbw has joined #dri-devel
kts has quit [Quit: Leaving]
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
<Mis012[m]> anyone has an idea why Unity would think `"#version 460 es"` is a thing
<Mis012[m]> according to https://answers.unity.com/questions/1645669/why-does-my-application-crash-at-start-ios-and-and.html (second log) it seems that someone had the same issue on actual android as well
<alyssa> Mis012[m]: mixing up gl and gles ?
<Mis012[m]> apparently
<alyssa> gles 3.3 when
<Mis012[m]> but clearly it doesn't fuck up this badly on (most) real android devices
maxzor has quit [Ping timeout: 480 seconds]
<Mis012[m]> and getting this
<Mis012[m]> presumably it gets confused by my "android device" having non-ES OpenGL, which is somehow not common on android despite Mesa having it on same hw
<Mis012[m]> not sure if freedreno is 3.2 or 3.3 now
<Mis012[m]> with 3.3 might hit the same shit
<Mis012[m]> on one hand it looks like it finds the newest GL supported and appends "es"
<Mis012[m]> on the other hand, surely they are not that stupid
<Mis012[m]> seems MESA_GL_VERSION_OVERRIDE=3.2 MESA_GLSL_VERSION_OVERRIDE=320 got rid of that issue... so maybe they are that stupid
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
jljusten has quit [Ping timeout: 480 seconds]
<Mis012[m]> now we have a sigsegv from SwappyGL...? sed
<Mis012[m]> it should allegedly log this, but seems like the issue might be missing eglPresentationTimeANDROID
Haaninjo has quit [Quit: Ex-Chat]
Jeremy_Rand_Talos has quit [Remote host closed the connection]
<Mis012[m]> does Mesa not have that?
Jeremy_Rand_Talos has joined #dri-devel
jljusten has joined #dri-devel
flto has quit [Quit: Leaving]
<Ristovski> Mis012[m]: mesa does seem to have EGL_ANDROID_presentation_time, hmm
<alyssa> Mis012[m]: it's apparently not trivial to get mesa to build GLES without GL :|
<Mis012[m]> well, I don't mind that :P
<linkmauve> alyssa, with -Dglx=disabled -Dgles2=enabled -Dgles1=disabled I do get a Mesa which doesn’t support GL I think.
<Mis012[m]> apps breaking when non-ES GL exists is the issue
<linkmauve> Programs not supporting GLES is also an issue, even if they could.
<Mis012[m]> it's only an issue when you're not using Mesa
<linkmauve> Or linking to libGL.so.1 when they actually should get their symbols from EGL.
<Mis012[m]> and non-Mesa drivers are sad
<Mis012[m]> I guess I didn't check it's NULL and not just malformed, but it's probably NULL
<alyssa> linkmauve: maybe it is that simple? I was told that didn't actually work for a silly reason but maybe I got bad data
<linkmauve> Mis012[m], well no, I use Mesa everywhere and when I build it with only GLESv2 support many programs are sad, either don’t provide acceleration or crash altogether.
<alyssa> android = gles, everyone else = gl, shrug
<alyssa> chomeos = gles, too
<Mis012[m]> but why would you not build it with gl
<linkmauve> alyssa, the weird part is Mesa still installs /usr/include/GL, even if it doesn’t support it.
<alyssa> linkmauve: thinking
<linkmauve> Mis012[m], Lima lies when it advertises GL 2.1 support, I’d rather get proper GLES 2.0 everywhere as that’s what the hardware is capable of.
<Mis012[m]> linking against libGL.so.1 makes total sense, the whole theatre with getSymbol only exists because of windows, it's not even called egldlsym so take a hint
<linkmauve> Mis012[m], well no, that comes with GLX dependency which means X11 dependency too, I’d rather not have to have that.
<Mis012[m]> Mesa should just commit to exporting those functions, I don't care where
<Mis012[m]> linkmauve: I doubt there are actual hw limitations for gl2 vs gles2, at best fw limitations
<linkmauve> There is no firmware on this GPU AFAIK.
<Mis012[m]> no way
<Mis012[m]> probably has it's own bootrom if it's not loaded from elsewhere
<linkmauve> Mis012[m], all the info is here: https://docs.mesa3d.org/drivers/lima.html
<Mis012[m]> >Note that the Mali GPU is only for rendering: the GPU does not control a display
<Mis012[m]> sad that this has to be stated
<linkmauve> Why? This is standard on most ARM platforms.
<Mis012[m]> it's the literal definition of CPU/GPU
<clever> the rpi is the same, v3d handles rendering, hvs/pv/hdmi handles the display pipeline
<linkmauve> Unlike desktop GPUs which do absolutely everything, from render to 2D composition to video decoding to video encoding to display driving.
<Mis012[m]> only x86 people use those terms incorrectly
<linkmauve> Guess where the majority of users come from. :p
<clever> the rpi is a bit more blurry though, its all in one chip, but there are clearly seperated peripherals within it
<Mis012[m]> desktop GPUs are pretty much SoCs
<clever> and the 3d rendering part has its own power domain, and can be turned off independantly
<linkmauve> alyssa, also funny that it installs /usr/include/GLES3/, even if the only enabled driver supports up to ES 2.0. :p
<Mis012[m]> if AMD designed their SoCs with unified address space like sane people, you could probably run Linux on the PSP core at worst if you don't find some better suited core lurking there
<Mis012[m]> from security perspective, the PSP can access anything it wants anyway
<Mis012[m]> just not in a way that's sane
<alyssa> linkmauve: whoops
<Mis012[m]> clever: well, I assume rpi has a standard AMBA architecture with multiple masters
<alyssa> linkmauve: in fairness that'd be difficult to change and i'm not convinced it would make sense to
<clever> Mis012[m]: yeah, the masters i'm aware of are the vpu, arm, v3d, hvs, vce, isp, dma
<Mis012[m]> the fun part about rpi is that it's effectively a videocore SoC featuring an arm coprocessor cluster
<clever> Mis012[m]: and the arm co-processor runs thru a custom mmu before it hits the proper master port
<clever> so the arm's view of memory can be totally different from the peripherals view
<Mis012[m]> not sure to what degree that's a matter of fw configuration like with qcom
<clever> its setup by start.elf on the official firmware
<clever> you have 64 pages, of 16mb each, controlling the lower 1gig of the addr space
<clever> on the videocore side, you have 1gig of ram, aliased 4 times, the top 2 bits of the address are cache control flags
<clever> with some peripherals shadowing ram at 0x7e00_0000
<Mis012[m]> basically every sus thing with qcom is a matter of sw configuration, just that sw is signed by someone other than the supposed owner and somehow people are fine with that being the norm
<clever> for the pi0-pi3 lineup, none of the signature checks are enabled
<clever> so with the right drivers/compiler, you can just replace the firmware and do whatever you want
<Mis012[m]> pi is a devboard, so it shouldn't have ever been accepted that they are enabled on pi4
alyssa has left #dri-devel [#dri-devel]
<clever> Mis012[m]: this is demoing the 2d core, the 3d core, and the arm core, all at the same time
<clever> Mis012[m]: i suspect the pi4 has sig checks enabled because they wanted a checksum, but all the rom had was hmac
<clever> and why respin the rom to add a weaker validation method?
<clever> and yeah, turning even the hmac on was a mistake, it led to 2-3 seperate people RE'ing the entire signing chain and cracking it wide open on every model :P
<Mis012[m]> so where do I download the private key
<clever> for the pi4, its a symetric signing algo
<Mis012[m]> wat
<clever> the validation key, is also the signing key
<clever> thats why they messed up :P
<Mis012[m]> I know what symmetric means
<clever> nobody cared to look, until it got in the way
<clever> with the proper start4.elf file, you can just dump the keys from your own pi
<clever> and every pi4 has the same hmac keys
<Mis012[m]> I guess it's not malicious then, they do give you the key :P
<Mis012[m]> qcom does security properly
<clever> but starting with the bcm2711B1T rev i think, they added rsa support to the boot rom
<clever> there are 4 rsa2048 pubkeys in the boot rom
<clever> and OTP is used to permanently disable those, and to enable RSA validation
<clever> from the factory, its still in hmac mode
<Mis012[m]> interesting
<clever> the rsa sigs, are part of the RPF custom secure-boot chain
<Mis012[m]> should still not be assholes and just release the key
<clever> "low" security, involves putting a user-generated rsa2048 pubkey into the SPI eeprom, and setting SIGNED_BOOT=1 in the SPI eeprom config file
<clever> the firmware will then expect a boot.img and boot.sig on the boot media, signed by that key
<clever> boot.img is just a fat32 fs, but in a file, on the SD fat32
<clever> all further firmware/kernels/config are inside that signed disk image
<clever> but "low" security can be defeated by just re-flashing the SPI eeprom
<clever> "high" security, involves burning the sha256 of the urer-generated rsa2048, into OTP, and turning on the RSA validation of the firmware
<clever> the official bootcode.bin firmware, will then enforce that the pubkey in SPI, matches the hash in OTP
<clever> so an attacker cant clear or change the pubkey
<Mis012[m]> bootrom fw is the only stock fw that should stay
<clever> Mis012[m]: and if they publish the privates for the rom keys, a the bootcode.bin could be maliciously replaced, and defeat the entire chain of trust
<Mis012[m]> the chain of trust should be verified by bootROM
<Mis012[m]> agsinst user supplied key
<clever> it is, but the root of trust is 4 keypairs, burned into the boot rom
<clever> and 1 keypair is already spent, it was used to sign binaries that dont enforce the chain of trust
<Mis012[m]> bootrom is mask rom
<clever> the setup directions explain how to revoke that key
<clever> yep
<Mis012[m]> OTP not being called fuses sounds like it's eprom?
<clever> one time programmable
<clever> all of the official docs call it OTP, but yeah, its basically just fuses
<Mis012[m]> qcom uses literal fuses
<Mis012[m]> other vendors don't say what it is, which makes you assume eprom
<Mis012[m]> since fuses are a pain to work with
<clever> the official docs say that 0->1 can be done, but 1->0 is never possible
<clever> 64 slots of 32bits each
<Mis012[m]> actually prom
<Mis012[m]> e is erasable
<clever> you can program a slot multiple times, but it will be a logical OR of the past and new value
<clever> so new bits can be set, but bits can never be cleared
<Mis012[m]> except they don't claim it's fuses
<clever> otp.c above, is a driver that can both read and write the OTP
<Mis012[m]> so maybe UV can change the bits
flto has joined #dri-devel
<clever> yeah, ive seen that done with AVR's before
<clever> but one issue, is what do you stand to gain by clearing the OTP?
<Mis012[m]> why do so many people misuse ' like this :(
<clever> ?
<Mis012[m]> AVRs is plural
<clever> ah
<clever> i can only see 3 real points to having the rpi secure-boot enabled
<Mis012[m]> clever: does it ship to users in a way where bootrom will allow booting non-rpif-signed fw?
<Mis012[m]> I didn't ever get that impression
<clever> the hmac checking is permanently enabled on the pi4 series, so you must dump the hmac key and sign your own blobs
<clever> rsa checking can be enabled by the users choice, but can never be disabled again
<clever> and the privates arent known, so your then stuck with the official stage-1 firmware
<Mis012[m]> now imagine they enabled rsa by defaults
<Mis012[m]> s/s//
<clever> the official stage-1 assumes that if RSA is enabled, OTP contains a sha256 of a user-chosen rsa pubkey
<clever> and if it doesnt match, it wont boot
MajorBiscuit has quit [Quit: WeeChat 3.6]
<clever> so turning RSA on at the factory would require programming a second rsa key, and now the user cant choose it
<Mis012[m]> official stage-1 is not something I'd want to use
<clever> until the ddr4 ram-init is solved, you dont have any choice on that
<Mis012[m]> apq8916 trm has ram training docs :)
<clever> but there is a middle-ground, caused by them adding bloody https to the stage-1 bootloader :P
<clever> originally, the eeprom contained just a bootcode.bin file, which did both raminit, and loading of start4.elf from sd/usb/tftp/nvme/rpiboot
<clever> but then they added the "network install" feature, which is just downloading a boot.img fat32 file, over https
<Mis012[m]> weird how qcom didn't let their engineers make a trm for 8996 after that :P
<clever> and the network stack, didnt fit within the 128kb limit for bootcode.bin
<clever> so the stage-1 got split into a stage-1 and stage-1.5
<clever> bootcode.bin now does just raminit, and loads bootmain.elf from SPI
<Mis012[m]> clever: can't you worst case just take the ram init assembly and use it as a blob
<clever> bootmain.elf then does booting from sd/usb/tftp/nvme/rpiboot/https
<clever> and in theory, i can just replace bootmain.elf in the spi eeprom
<clever> and bootcode.bin is now far dumber, its incapable of network/sd/usb access
<clever> so you can just use the blob as-is, its got a far smaller attack surface
<clever> but, the chain of trust is maintained, by having the sha256(bootmain.elf) embedded inside bootcode.bin, which itself is signed
<Mis012[m]> except it checks for the wrong signature?
<clever> so i would have to patch bootcode.bin to update the bootmain.elf signature
<clever> then re-sign bootcode.bin with the extracted hmac keys
<clever> and then never enable rsa mode
<Mis012[m]> sounds worth pursuing
<Mis012[m]> >js
<clever> this can sign a bootcode.bin, given you have a keys.js with the keys
<clever> i know the nodejs crypto libs, so thats my answer to most crypto things
<clever> you can always re-implement it in another language
<clever> this module can be compiled into a start4.elf file, launched with the official stage-1 firmware
<clever> and then it will print the hmac keys to the uart, in a format suitable for pasting directly into keys.js
<clever> then sign.js can sign custom stage-1 files
<Mis012[m]> well, good to know
<clever> every pi4, pi400, cm4, and cm4s (not plural), uses the same hmac keys
<clever> dump once, own the entire bcm2711 series :P
<Mis012[m]> now to sleep, and tomorrow figure out what exactly causes the sigsegv
<clever> this program will parse the signature at the end of a stage-1 file
<clever> and print both the hmac and rsa sigs, and tell you which rsa key was used
<clever> and if you have a pubkey${n}.pem, it can validate the rsa sigs
<clever> same for keys.js, and validating the hmac sig