02:42 RSpliet: meh, one context switch failed after at least 8,6 million successful ones...
04:34 pmoreau: karolherbst: Nothing major. Some deconnections or difficulties to connect to networks, but for some short periods of time
04:36 karolherbst: pmoreau: mhh odd
04:36 karolherbst: pmoreau: with the b43 driver it only connects like 10% of the time and then only after boot
04:36 karolherbst: pmoreau: you also have a bmc4321?
04:39 pmoreau: I'll check tonight
04:39 karolherbst: thanks
04:40 pmoreau: You might need to ping again later tonight, as I might have forgotten by then :-D
04:42 karolherbst: well it isn't as critical, because it's for the max mini, but still would be nice if that would work reliable
04:46 pmoreau: Sure!
04:47 karolherbst: pmoreau: nvac was your main gpu, right?
04:47 pmoreau: Yep
04:47 karolherbst: mhh
04:47 karolherbst: can you turn it off?
04:48 pmoreau: I think it is turned off when I switch to the G96 using vga_switcheroo
04:48 karolherbst: I have a "\_SB_.PCI0.IXVE.IGPU._DSM" method and was thinking maybe I can turn mine off to
04:48 karolherbst: but it is the only gpu
04:49 pmoreau: Well, you can try and see what happens
04:49 karolherbst: well
04:49 karolherbst: vgaswitcheroo only works with two gpus
04:49 karolherbst: and sadly bbswitch can't handle that DSM call
04:50 pmoreau: Right, but it should be possible to hack vga_switcheroo to work with only one GPU?
04:50 karolherbst: mhhh
04:50 karolherbst: maybe
04:51 karolherbst: well it makes sense kind of
04:51 karolherbst: if the gpu isn't in use
04:51 karolherbst: why keep it alive?
04:52 pmoreau: To warm the CPU, remember? :-D
04:57 karolherbst: :D
04:57 karolherbst: well
04:57 karolherbst: I plan to run that machine fanless
05:21 karolherbst: pmoreau: well I think I try to get it to work with bbswitch first, it seems there is some acpi issues left
05:37 karolherbst: pmoreau: mhh odd, I managed to put the gpu in D3cold state, but nothing changed with the heat
05:38 pmoreau: :-/
05:38 karolherbst: maybe I should get nvidia running and see if there is any change in the temperature
05:39 pmoreau: Would (for some weird reason) the sensor cache its old value?
05:39 karolherbst: the precision is too high
05:39 karolherbst: the value changes
05:40 pmoreau: K
05:42 karolherbst: I can't imagine it isn't possible at all
05:45 DrWhax: mupuf: Hi! I'm a contributor to the Tails team, were looking into ways to effectively clear the VRAM to counter the following attack: https://hsmr.cc/palinopsia/. We looked into slram to directly write to the video memory, I wonder if this is a correct approach or if we could use the nouveau driver for any of this.
05:46 mupuf: DrWhax: hey, great. You contact me because of the presentation I gave at XDC2012?
05:47 DrWhax: mupuf: I got refered to you by RSpliet :)
05:47 mupuf: ok
05:47 mupuf: well, this is definitely solvable for all open source drivers
05:48 mupuf: it is going to come at a cost, but there are mitigation techniques
05:48 karolherbst: mupuf: there could be a drm boot options maybe?
05:48 mupuf: karolherbst: security should not be an option
05:48 mupuf: it should be a default
05:48 karolherbst: yeah, depends on the costs though
05:48 mupuf: and if we are smart enough, we may reduce the cost to be negligeable
05:48 karolherbst: right
05:49 karolherbst: but then timing might be important too
05:49 karolherbst: the most secure way is to clear buffers when they get unused
05:49 mupuf: in any case, the presentation Tim and I gave at XDC2012 contained some information and discussions
05:49 mupuf: let me find you the link
05:50 mupuf: karolherbst: not really, you just need to clear them when the pool of cleared buffers is empty
05:50 karolherbst: mupuf: mhh and in the meantime?
05:50 mupuf: and you need to allocate buffers from the application's pool as much as possible
05:51 karolherbst: yeah, but I think they want a rock solid method
05:51 mupuf: then you need to have a background task that clears buffers
05:51 karolherbst: where you can't read out memory at any given point in time
05:51 karolherbst: *used buffers
05:51 mupuf: a simple method is to clear buffers on demand
05:52 mupuf: karolherbst: that is not really what the attack is showing
05:52 mupuf: it shows two different GL apps getting buffers with the content of another app
05:52 karolherbst: no
05:52 karolherbst: two different apps
05:52 mupuf: on unloading the driver: clear the RAM --> this one should be easy to implement
05:53 mupuf: DrWhax: http://www.x.org/wiki/Events/XDC2012/XDC2012AbstractMartinPeres-Timoth%C3%A9eRavier/
05:55 mupuf: DrWhax: We will need this feature in the kernel drivers at some point or another
05:55 mupuf: so you should not get too much resistance
05:56 mupuf: but I would suggest you implement the concept of pool of pages per graphic context
05:56 mupuf: and having a pool of cleared buffers
05:57 mupuf: whe the pool of cleared buffers is empty, it should reclaim pages from the apps' unused pages
05:58 mupuf: that should be an effective way of reducing the memory bw consumption needed for clearing buffers
06:00 mupuf: DrWhax: I am not going to lie to you, this is not a trivial task
06:01 mupuf: but if you do it in TTM, you get both nouveau and radeon in one go
06:01 mupuf: if you can do it at the GEM level, you do it for all the open source drivers
06:01 mupuf: so it has a high reward :)
06:10 karolherbst: pmoreau: funny though, the temperature with nvidia isn't really lower
06:31 DrWhax: mupuf: thanks for the explanation!
06:32 DrWhax: mupuf: and that's great that we'd be able to get both in one go!
07:34 DrWhax: mupuf: am I free to quote the chat on the ticket?
07:35 RSpliet: DrWhax: #nouveau is logged - see the IRC topic. You can even refer to that if you like ;-)
07:35 DrWhax: cool :)
08:19 karolherbst: mupuf: any idea how to reduce heat of tesla cards by a lot?
08:19 karolherbst: usually any method welcome as long as it doesn't include changing the gpu phyisically
08:22 imirkin: reduce clocks?
08:23 karolherbst: this lowers temperature by 1°C
08:23 karolherbst: it is a nvca gpu, no volting
08:24 imirkin: probably some clock gating that could be enabled
08:25 karolherbst: mhh
08:25 karolherbst: sadly nvidia isn't much lower
08:25 karolherbst: with nvidia I got to like 72°C?
08:25 karolherbst: well this is still 5°C lower than nouveau :D
08:26 imirkin: tesla runs hot. get used to it.
08:26 imirkin: my G96, on which i ripped out the fan, ran at 90C. and it was totally fine.
08:26 karolherbst: even full idle?
08:26 imirkin: yes :)
08:26 imirkin: [but without the fan that it came with]
08:27 karolherbst: mhhh
08:27 karolherbst: I planned to run this mac mini without a fan
08:27 karolherbst: I am more worried about the cpu if the gpu produces so much heat
08:27 karolherbst: maybe I just try it out and look how that goes
08:51 karolherbst: pmoreau: I think the antenna wasn't fixed right...
12:54 CaptainCoward_: to what extent does nouveau guard against a malicious video rom? does it ever execute x86 instructions that come from the video rom? a glance at the source code seems to indicate that most functions are actually implemented in code and the rom is only used as a kind of selector of what to run at what time, but I have only looked briefly at it. is this true for all cards?
12:56 CaptainCoward_: the part I am looking at is nvbios_init_opcode struct in init.c
12:56 CaptainCoward_: and nvbios_init in the same file
13:28 airlied: CaptainCoward_: it doesn't execute x86 instructions
13:29 airlied: it just parses tables stored in the BIOS and executes a sort of small instruction set
13:29 airlied: though I'm not sure how much damage that instruction set can do
13:43 mwk: as much as it wants, unlimited access to MMIO registers equals access to physical RAM
13:44 mwk: or, for that matter, it could upload something to one of the falcon processors and launch them
13:44 mwk: even better, since GPU auto-runs a special kind of script from the VBIOS, it can actually do damage without any interaction from host
13:45 CaptainCoward_: ho hum, how does it "auto-run" the script?
13:46 mwk: as soon as it gets power, it fetches a mini-script from a const address in the ROM
13:46 mwk: which is limitted to MMIO register writes
13:46 mwk: but... MMIO register writes are powerful enough to bootstrap a falcon processor
13:46 CaptainCoward_: I will be booting with coreboot, which will be configured not to run the pci rom
13:46 mwk: that doesn't matter, GPU runs it on its own
13:47 CaptainCoward_: absent a part of the pci-e spec that allows for a pci device to comandeer the processor, I'm assuming that can't happen
13:48 mwk: any PCI device can access system RAM unless you happen to have a machine with IOMMU that is actually enabled
13:48 mwk: heck, the script/falcon can even write to its own PCI config space to enable bus mastering
13:49 mwk: the host doesn't have to do absolutely anything
13:49 CaptainCoward_: I was assuming a pci device can't do anything before it is configured. does linux enable this iommu?
13:50 mwk: yeah, well... in theory it shouldn't
13:50 mwk: but then, malicious ROM is malicious
13:50 CaptainCoward_: I mean the bus hardware should ignore anything from a device that hasn't been initialized yet
13:51 mwk: linux may enable the iommu, but the gpu auto-runs the script instantly, before linux is booted
13:51 mwk: the bus doesn't know if you initialized the hardware or not
13:51 CaptainCoward_: I always thought the rom was run by the bios
13:52 mwk: though I suppose you could be safe if you avoid initializing the pci-pci bridges before the device
13:52 mwk: most of it is, yes
13:52 mwk: but there's auto-run script that is run by the GPU on power-on
13:52 mwk: and it can do arbitrarily complex things by chaining to one of the on-GPU processors
13:53 mwk: which btw is not just theory, Kepler GPUs actually boot the PMU falcon without any assistance from host
13:54 CaptainCoward_: what the heck is falcon?
13:54 mwk: an on-gpu microprocessor
13:54 mwk: it can do basically anything
13:55 CaptainCoward_: well I don't care what the gpu does on in its own little island. I just don't want it to be able to read host memory.
13:55 skeggsb: without an iommu in the way, you can't really stop it...
13:56 CaptainCoward_: so what if I boot linux and then hotplug the graphics card into the pcie slot?
13:57 mwk: for one, you void your warranty for the motherboard and the gpu...
13:57 mwk: but then, that could work
13:58 mwk: though I sure hope you only do that once to flash the ROM with 0s
13:59 CaptainCoward_: why?
13:59 mwk: ... because hotplugging a GPU is not exactly convenient?
14:00 CaptainCoward_: not a big deal ... uptimes of months here
14:02 mwk: I suppose with coreboot it'd be possible to force the right sequence of enabling PCI bridges and iommu to do it all safely without hotplugging though
14:02 mwk: you might have to modify the kernel to expect an iommu on boot, but oh well
14:03 mwk: unless the bus system is sophisticated enough to fully start itself...
14:04 CaptainCoward_: well I am not spending a month coding and debugging to eliminate a 10s manual operation done a few times a year
14:05 CaptainCoward_: but the confusing thing here is how does linux use the iommu to restrict the memory access of a device that hasn't been plugged in yet? is there a default level of access after the iommu is enabled that is conservative?
14:06 mwk: *shrug* I have no idea about iommus, I don't think I ever had a machine with one
14:06 mwk: except AGP GART, which doesn't really count
14:10 CaptainCoward_: well amd kabini which is my current test system seems to support iommu. is there a proc or sys file I can look at to see if linux has actually enabled it?
14:11 CaptainCoward_: amd_iommu_v2 is loaded
14:21 CaptainCoward_: ah. dmesg reports "AMD IOMMUv2 functionality not available on this system" during boot
14:24 CaptainCoward_: the number of iommus is loaded from the acpi tables
14:30 CaptainCoward_: anyone know the flag name for AMD-Vi in /proc/cpuinfo?
14:42 CaptainCoward_: apparently there is no separate flag, but athlon5350 should have an iommu, but this kind of thing needs to be enabled by the bios.
14:42 CaptainCoward_: I will ask the coreboot people if they have any suggestions
19:12 AlexAltea: I came accross this formula to do RAMIN addr -> VRAM addr:
19:12 AlexAltea: real VRAM address = VRAM_size - (ramin_address - (ramin_address % reversal_unit_size)) - reversal_unit_size + (ramin_address % reversal_unit_size)
19:12 AlexAltea: I'm too sleepy to do maths atm, does anyone have the VRAM addr -> RAMIN addr formula?
19:13 AlexAltea: (this is NV03 - NV40)
20:16 mwk: AlexAltea: the formula works both ways
20:17 mwk: as in, it's its own inverse
20:18 mwk: I must've been sleepy myself when I wrote this, the formula is simply: VRAM address = ramin_address ^ -reversal_unit_size
20:19 mwk: hmm
20:19 mwk: scratch that
20:20 mwk: vram_address = vram_size + (ramin_address ^ -reversal_unit_size)
20:21 mwk: so, ramin_address = (vram_address - vram_size) ^ -reversal_unit_size
20:23 mwk: I think if you do the math carefully the formulas are actually the same, given that vram_size is divisible by reversal_unit_size