06:50 <JensGlathe[m]> craftyguy steev since it just happened on a wdk2023 again: no HTC Rx errors since wednesday on X13s with iwd and msi-map off on pcie4. It's an odd workaround, but it is.

11:19 <SpieringsAE> I've been doing some u-boot stuff and I had some thoughts. So u-boot currently does not implement the uefi runtime service for efivars, this makes it so stuff like efibootmgr doesn't work etc. Theoretically u-boot can do these operations just fine to some spi flash or something,

11:19 <SpieringsAE> the issue is that this spi-flash memory most likely is not operated by special 'secure' hardware, so the linux kernel will also have access to this flash.

11:19 <SpieringsAE> So if u-boot was still working on the spi-flash there could be a conflict with the actual kernel. So what if you just let u-boot die on boot like usually and then mount efivars directly from the spi-flash in linux.

11:20 <SpieringsAE> you could mark some spiflash part as efivars in the dts, uboot can do its efivar business when it is running, and then linux will just take over when it gets there

11:23 <SpieringsAE> so like here: https://github.com/DC-DeepComputing/DC-linux/blob/122cb71785ac48069af6ea07d3d6bd7fa5c301ee/arch/riscv/boot/dts/starfive/jh7110-common.dtsi#L409-L440

11:24 <SpieringsAE> you would add a partition called efivars, and some driver could pick that up, register the efivars/ops and boom

11:26 <SpieringsAE> you could add maybe like a compatible = "efivars"; to one of the partitions, not sure if that would be allowed by the defenition but jeah

11:26 <macc24> isn't the whole point of efivars the fact that efi can also read them?

11:26 <SpieringsAE> yes which it can

11:26 <SpieringsAE> u-boot can have full access to it while it is alive, but then give up access and pass it to linux when it boots

11:27 <SpieringsAE> the efi runtime is still in u-boot, but I believe when exit_boot_services or something like that gets called, u-boot kinda just dies

11:30 <SpieringsAE> I guess that does violate the efi spec, but its better than nothing untill we actually get these secure spi interfaces

13:15 <SpieringsAE> just did some testing with my girlfriends FLIR thingy, it says the area around the charging/sd-card reader get up to 40+ degrees when the laptop is set on its side with no obstruction

13:15 <SpieringsAE> when it is in a normal position as it would be on your lap, it can get up to 50+ degrees there

13:15 <SpieringsAE> that is bottom surface of the laptop temperature on the asus vivobook s15, very spicy

13:24 <macc24> just like the ibm thinkpads back in the day

13:41 <travmurav[m]> SpieringsAE: iirc there was some tool in linux for "special" efivar backends like /esp/efivars.txt for u-boot

13:41 <travmurav[m]> so like linux fully implements it internally and just updates the file/partition/whatever

13:42 <travmurav[m]> or maybe s/was/was discussion about/

13:42 <travmurav[m]> not sure

13:42 <travmurav[m]> but can probably do the same way as qcom

13:43 <SpieringsAE> yeah there is efivars as a file implemented in u-boot

13:44 <SpieringsAE> this is more interesting to me though: https://lore.kernel.org/all/20231126220836.374956-1-i@shantur.com/

13:44 <SpieringsAE> sadly that patchset seems to have died there and then

13:45 <travmurav[m]> but tbh without some always-running (i.e. tz on arm or whatever thing on x86) domain controlled by u-boot I don't think it's easy

13:45 <travmurav[m]> as in

13:45 <travmurav[m]> if you give up a spi controller to runtime services, you'd need the "owner" of the controller to turn it on/off to save power properly and not break low power states

13:46 <travmurav[m]> so it'd probably be very special stuff

13:46 <travmurav[m]> in which case lettin linux write to the txt file sounds simpler xD

13:47 <SpieringsAE> yeah this spi controller needs to be designed to be used like this

13:47 <SpieringsAE> which currently does not happen

13:48 <travmurav[m]> I think on qcom/x86 the tz/whatever can "tick" whenever it wants, and especially run when the device suspends/resumes since (at least on arm) you'd call psci into tz to do so

13:49 <travmurav[m]> so on qcom they can claim some blocks and vote them on/off safely

13:51 <SpieringsAE> I just want to get rid of the firmware layer for efivars in this situation, it just doesn't exist anymore

13:52 <SpieringsAE> so Linux is the only one controller the hardware at that point

13:53 <kettenis> Linux and u-boot would have to agree on the format of the variable storage (and its location)

13:53 <kettenis> but I guess you could adopt the format that u-boot already uses to store the variables in a file on the ESP

13:54 <SpieringsAE> there is no standard for this? but yeah in this case that seems like a fine compromise

13:59 <SpieringsAE> checkpatch.pl: perl: warning: Setting locale failed.

13:59 <SpieringsAE> aaaaaaa

14:00 <SpieringsAE> I've done this before why is it complaining now

14:00 <SpieringsAE> guess it doesn't really matter

14:03 <SpieringsAE> I think kde is doing something silly

14:15 <kettenis> https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage

14:16 <kettenis> that is the standard for storing efi variables in a file

14:22 <kettenis> And this commit explains how the OS is supposed to "save" the variables at runtime:

14:22 <kettenis> https://source.denx.de/u-boot/u-boot/-/commit/00da8d65a3baea8c3745367bea99b1d76f8f129c

14:24 <kettenis> the #u-boot channel on the libera irc server is probably a better place to discuss this

14:47 <macc24> alpernebbi?

15:15 <alpernebbi> I'm aware of ubootefi.var but had some issues with the fat32 partition that contains it getting corrupted, so I usually disable that

15:17 <alpernebbi> it would be nice if we had kernel support for it as a efivarfs backend or something, second best choice is userspace tools supporting it

15:18 <alpernebbi> or rather an ebbr-specified file path and that format

15:20 <alpernebbi> or a similar spec-agreed SPI flash region please

15:23 <alpernebbi> I guess if we do things as "efivarfs backends" we can even support multiple schemes, choose the proper one for the device seamlessly

15:25 <alpernebbi> one thing I see not mentioned in backlog is using emmc rpmb parts, https://www.linaro.org/blog/protected-uefi-variables-with-u-boot/

15:25 <alpernebbi> which I dislike because it looks like you'd have to 'lock' the device to one signed implementation forever

15:29 <alpernebbi> macc24: o/ ^^

15:29 <macc24> hi

15:29 <macc24> im somehow still alive

15:30 <alpernebbi> always glad to hear from you

15:32 <kettenis> the emmc rpmb approach results in too much complexity

15:32 <kettenis> and who cares about secure boot? ;)

15:36 <SpieringsAE> I've never really used the ubootefi.var file approach, but it also doesn't really fix the big problem, it will still need to be on one specific device on one specific partition

15:36 <SpieringsAE> spi flash would be a central position that everyone can agree on

15:36 <kettenis> not all devices have spi flash though

15:37 <SpieringsAE> yep for those there will be other solutions like rpmb or the file

15:37 <SpieringsAE> but every device where you would require this will most likely have spi flash, some open source laptop thingy like the pinebook pro for example

15:38 <alpernebbi> I've got a very pessimistic view for the trusted computing future, where everyday websites will require your computer to be "secure and attested" to provide their services to you at all

15:39 <alpernebbi> IMO "every device where you would require this" is every device, SBCs and whatnot included

15:45 <alpernebbi> well it could have been a priority list of where it should be stored, like spi > emmc > sdcard

21:38 <steev> JensGlathe[m]: i havent seen them at all in 6.12

21:38 <JensGlathe[m]> nice

21:38 <steev> with just the msi-map removed

21:39 <JensGlathe[m]> iwd ftw

21:39 <steev> no iwd here, have not had a chance to figure out why it causes my x13s to reboot

21:39 <JensGlathe[m]> oh it was a mess until 6.13-rc6though

21:39 <JensGlathe[m]> this is a bit vile of iwd

21:40 <JensGlathe[m]> they use different libraries (iwd and wpa-supplicant) so probably different ioctl patterns

21:43 <JensGlathe[m]> but how do you tackle the debug of this I wonder

21:43 <JensGlathe[m]> There must be something not thread/interrupt safe in the firmware

21:43 <steev> well it doesnt happen to craftyguy, and i think hes also using debian

21:44 <steev> but even if not, should still be 3.3

23:55 <Elon_Musk> Starlink today & the 1st Month is on me ! Limited Time Offer/ PROMO CODE YOLO ! http://star.linkrelay.com/