04:11Lyude: RSpliet: eh, i'm kind of glad honestly
04:12Lyude: crypto currency is absolutely horrible for the environment, it'd be great if it could just go away entirely
04:19damo22: i did a bit of digging, i think the signatures on the nv firmware could be ed25519 or ecdsa https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages
04:20Lyude: note that dmca means we can't really just break nvidia's encryption, even if we were to know how to :\
04:21damo22: im not breaking anything, im trying to find a number
04:21Lyude: ah\
04:22imirkin: why do you think elliptic is likely?
04:22damo22: because the sig is only 64 bytes long
04:23damo22: 64*8 = 512 bit RSA would be pretty easy to break
04:25imirkin: some kind of AES256-HMAC seems more likely
04:27damo22: isnt that symmetric?
04:28imirkin: what seems to be the problem?
04:29damo22: i found AMD's symmetric key baked inline in the SMU firmware
04:29imirkin: more likely it's on-chip
04:29imirkin: since it's the chip which rejects the firmware
04:30damo22: or its in the blob
04:30imirkin: lol no
04:30imirkin: the signature is baked into the blo
04:30damo22: ive seen dumber
04:30imirkin: i bet. but nvidia is, sadly, good at this
04:31damo22: i thought the sig is in the lib/firmware/nvidia/*/*_sig.bin
04:32imirkin: for nouveau, sure
04:32imirkin: but blob has the firmware and signatures baked into it
04:33damo22: but if the sig is loaded into the card for checking separate from the fw, that means there must be some hardware checking mechanism independent of nvidia's blob
04:34imirkin: the key is loaded into the chip
04:34imirkin: it checks the signature
04:34damo22: what is your understanding of the sig.bin files? what are they
04:34imirkin: the signature.
04:34damo22: ok
04:35imirkin: for the corresponding data
04:35damo22: ok so the sig is checked even for nouveau?
04:36damo22: if so, that means there is a hardware checking mechanism that does not live in the blob
04:39imirkin: the signature is checked by the hw.
04:39imirkin: i thought i mentioned that.
04:39damo22: 0k
04:39damo22: just making sure
04:42damo22: hw_function(key, data.bin, sig.bin) = {pass,fail}
04:43damo22: i suppose its something like that
04:46imirkin: something like that.
04:46imirkin: it actually has to do with flipping into "high secure" mode
04:46imirkin: for the falcon engine
04:46damo22: but if its a HMAC, maybe the key is baked in the sig.bin at offset 0x40 since there are a few more bytes than 64 :D that would be funny
04:49imirkin: there's formatting in the file
04:49imirkin: iirc
04:49imirkin: like a 4-byte magic header i think?
04:50damo22: its at the tail
04:50imirkin: anyways, a HMAC-AES256 key would be 32 bytes
04:50imirkin: could be a crc? dunno
04:53damo22: _inst.bin is code?
04:53imirkin: dunno offhand
04:54damo22: would be cool if the code was not digested as part of the signature, only the data
04:59damo22: hmm on some models there is no sig.bin file
05:01damo22: maybe you can bypass the check simply by not loading a signature
05:03imirkin: no.
05:04damo22: or setting some kind of flag in the "metadata" of the sig.bin to zero or some special value
05:04damo22: i bet they put overrides in somewhere
05:19damo22: gm200/gr/fecs_sig.bin 00000040 01 00 00 00 01 00 00 00 02 00 00 00 |............|
05:19damo22: gm200/gr/gpccs_sig.bin 00000040 01 00 00 00 01 00 00 00 03 00 00 00 |............|
05:19damo22: {02 = fecs, 03 = gpccs} the other 01 fields are interesting
05:20imirkin: sigh
05:20imirkin: you can look at the code that parses the signature file in nouveau.
05:20imirkin: to learn the precise format of that file
05:21damo22: well i cant see your source repo on gitlab
05:24imirkin: https://github.com/skeggsb/nouveau/blob/master/drm/nouveau/nvkm/subdev/acr/hsfw.c
05:24imirkin: (HS = high security)
05:25imirkin: you'll have to walk around the code a bit to figure out where the sig file is loaded
05:25imirkin: grep for request_firmware
05:28damo22: thanks
05:46damo22: as far as i can see, the firmware is the entire file including offset 0x40 -> end
05:47damo22: ret = nvkm_acr_lsfw_load_bl_inst_data_sig(&gr->base.engine.subdev, &gr->fecs.falcon, NVKM_ACR_LSF_FECS, "gr/fecs_", ver, fwif->fecs);
05:48damo22: the 02 and 03 in the file seem to be duplicated as part of the enum NVKM_ACR_LSF_*
05:49damo22: but the hardware probably checks those against the sig so it knows which sig it is
05:50damo22: s/firmware is the entire file/sig is the entire file/
06:27damo22: my guess is offset 0x40 and 0x44 are special flags to set something like, "disable strict checking of signature" and/or "production / debug mode"
06:28imirkin: uff, this nv50 image thing is actually a little annoying. if we ever get a linear image, it has to be treated different from tiled in terms of coords
06:29imirkin: lots of conditional code i guess
06:36imirkin: hm, fun. the tiled case appears to work on the diagonal only.
06:36imirkin: oh, no, i see. it's because it wants ssbo AND images at the same time
06:36imirkin: which is "for later"
06:37damo22: is there any way to tell if nva0 fails the sig check if i fiddle with firmware?
06:39imirkin: nva0 doesn't do signed firmware
06:39imirkin: GM200+ does signed firmware.
06:40damo22: aha
06:41damo22: i cant test my theories then
07:24imirkin: alrighty ... made some good progress on nv50 images. i can now successfully write both buffer and tiled images.
07:25imirkin: now i need to figure out what to do about format-less writeonly images
07:25imirkin: and allow images + buffers to be used at the same time
11:26karolherbst: imirkin, skeggsb: with the current libdrm API, once a pushbuffer gets kicked, does the user have to ref all bos again unless there are in an active bufctx?
15:21imirkin: karolherbst: yes
15:21imirkin: if they're in a bufctx, they're auto-added on submit
15:22imirkin: this is why some places carefully do PUSH_SPACE
16:08karolherbst: yeah.. I noticed.. in my rework I was kicking too often and hence I saw write faults in some applications :)
16:08karolherbst: but now even the android emulator seems to run
16:08karolherbst: and this one I saw creating like 100 threads
16:08karolherbst: (not all GL, but..)
16:09karolherbst: now I run into some btrfs bugs :D
16:09imirkin: blame nouveau!
16:10imirkin: pmoreau: btw, looks unlikely that i'll be able to finish the nv50 compute work this weekend -- probably the one after that is more likely. but i've made good progress.
16:10karolherbst: imirkin: ehhh... :D
16:11imirkin: pmoreau: if you're interested in further hacking, i'd probably have time to polish up some patches to look semi-presentable, but i'd rather not waste time on it now if you won't look either
16:11karolherbst: but I am quite happy that the emulator doesn't take down my entire machine :)
16:11karolherbst: and it does seem to work alright now :)
16:11imirkin: just the filesystem.
16:11imirkin: and who needs *that*
16:11karolherbst: well.. not even that
16:11karolherbst: it just some btrfs bug where it waits on an even which never arives
16:12karolherbst: triggered by a handle_mm_fault
16:12karolherbst: well.. kvm_mmu_page_fault actually
16:12karolherbst: something something stupid
16:13karolherbst: the annoying bit is just that the qemu process is a zombie which I can't get rid of
16:13imirkin: boo
16:13karolherbst: and starting a new VM doesn't work, because one already has the image opened :D
16:13karolherbst: and I am too lazy to reboot now
21:01ullbeking: Hello all
21:02ullbeking: Can somebody please recommend a supported card that performs well, but especially is _quiet_?
21:05FLHerne: "well" is slightly relative with nouveau :p
21:05FLHerne: Recent cards lack reclocking (needs signed firmware) and thus are extremely slow; older ones are old
21:05imirkin: ullbeking: the fanless ones probably? also define what you mean by 'supported'
21:06imirkin: (or rather 'performs well')
21:06FLHerne: And older fast-for-their-time cards are generally power-hungry and thus noisy
21:06ullbeking: imirkin: FLHerne: if a fanless card is going to not overheat, does that mean its power management must be supported well in this table? https://nouveau.freedesktop.org/PowerManagement.html
21:07imirkin: dont worry about that table ... any semi-recent card will be fine as far as overheating is concerned
21:07imirkin: (semi-recent = in the past 10y)
21:08ullbeking: brb, dinner just got served. thx already so far, FLHerne and imirkin
21:22ullbeking: i've been looking for GT 1030 but can't find it in the list of supported chips
21:23ullbeking: That's the one that I saw that I want, if it were supported
21:24imirkin: i'm using one right now
21:24imirkin: perf will be much lower than nvidia blob
21:24imirkin: and you won't get video decoding/encoding accel
21:28ullbeking: ty for the info, imirkin
21:32ullbeking: Why did you choose the gt 1030 yourself, imirkin ?
21:33imirkin: i'm one of the nouveau developers
21:33imirkin: i need cards from every gen
21:33imirkin: this one happened to be in a dell desktop that didn't need it
21:34imirkin: so i grabbed it :)
21:49ullbeking: is there a different card you'd recommend that would still be quiet but have better performance than the gt 1030?
21:49ullbeking: imirkin ^
21:50imirkin: not really
21:50imirkin: you're not going to get good perf with nouveau from any GTX 9xx or later
21:50imirkin: due to the reclocking situation
22:02ullbeking: 21:24 <imirkin> and you won't get video decoding/encoding accel
22:02ullbeking: so even for mere playback, there would be no acceleration... if this were a media server, would this be considered a basic requirement?
22:03imirkin: definitely desirable
22:10ullbeking: in this case, considering this is one of the use cases of this home server, what GPU would you recommend, then? would you go for Nouveau or some other, non-Nvidia based GPU?
22:11imirkin: either intel or amd apu would be best
23:48Lyude: woah, I did not notice nvidia dropped nvenv/nvdec/nvjpg class files for tegra in open-gpu-docs