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