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