Summary: -------- A combination of weaknesses in the android GPU driver (kgsl) and ion as deployed on snapdragon devices allow access to physical memory to non- privileged user. This effects snapdragon devices with adreno 3xx, with per-process pagetables enabled (CONFIG_KGSL_PER_PROCESS_PAGE_TABLE=y). I have not checked if adreno 2xx devices are vulnerable to similar sort of attack. It is not an easy attack, but I believe it should be taken seriously as it could allow root access on a wide range of devices. A proof of concept is enclosed, which writes "Kilroy was here" to a dummy buffer (victim) with a known physical address, for purposes of concept. Before: [ 11.974607] ###### victim=c11ac000 (813ac000): "" After: [ 33.401709] ###### victim=c11ac000 (813ac000): "Kilroy was here" Note that this issue is addressed by the following security update: https://www.codeaurora.org/projects/security-advisories/unprivileged-gpu-command-streams-can-change-iommu-page-table-cve-2014 See also: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0972 Background ---------- In the process of researching how kgsl implements per-process pagetables, before implementing a similar feature in the upstream msm drm/kms driver, I realized that the IOMMU context registers are mapped into the GPU's address space and are updated by the CP (command processor). This enables fast GPU process switching without a massive performance penalty. But it seemed risky and I needed to make sure I understood the implications. Note that while this exploit does require some knowledge about how the GPU operates, it does not require any knowledge about registers typically programmed from closed src userspace GL drivers, etc. Description: ------------ The GPU has two address spaces, essentially the "user" address space, and the "supervisor" or protected address space. Switching between the two, in order to gain access to the IOMMU context registers in the "supervisor" address space can be accomplished by a simple register write (to CP_STATE_DEBUG_INDEX) from a userspace crafted command-stream. There are a few hurdles: 1) You need to construct replacement first and second level IOMMU pagetables in physically contiguous memory, at a known physical address. Also the physical addresses of everything to be mapped in the new pages needs to be known. 2) In the supervisor context, the userspace crafted command-stream buffer will become no longer accessible. The first hurdle is quite low, thanks to ion. There are a number of carve- out ion pools at known physical addresses, if you can be sure to allocate while the pool is not in use, you get a buffer at a known PA. In my proof- of-concept, I used the 'mm' pool. The second hurdle is handled by writing the commands that will actually do the context switch into the global 'setstate memory', which is mapped at the same gpu virtual address in both supervisor and user contexts. The physical address of this buffer is not very easily guessable, but the GPU virtual address is. So we simply construct two identical contextswitch command buffers, one directly in our setstate mirror, and one indirectly via writes from command-stream into the original 'setstate memory'. Then take care that the two copies are mapped at identical GPU virtual address in the new page-tables. Once that is accomplished, simply do an IB to the setstate memory, and when you return from that indirect-branch you have your new pagetables installed. So the sequence is: 1) allocate ion buffer at known address. The first 32K of this buffer are used for first and second level pagetables. The next 4K for the setstate mirror we create, and the remaining for command-stream. The pagetables created should have mappings for: a) ion buffer, at same gpu virtual address b) iommu context registers, at same gpu virtual address c) setstate mirror, at same gpu virtual address as original setstate d) and of course mapping for the target memory to overwrite (or read) 2) Build command-stream buffers with instructions to switch to supervisor mode, and perform context-switch in setstate mirror. 3) Build first-level command-stream (what we pass to issueibcmds ioctl): a) first instructions to write the same contents as the setstate mirror into the real setstate buffer. b) then perform IB (indirect branch) instruction to jump the commands we just wrote into setstate memory. 4) When the instructions executing in setstate memory switch to super- visor mode, no fault is generated because the setstate memory is mapped in the same location in supervisor mode. 5) And when the instructions executing in setstate memory switch to the new pagetables by writing TTBR0/TTBR1 in the IOMMU registers, no fault is generated because the setstate mirror is mapped at the identical location to original setstate page. 6) Then return from IB back to first level command-stream buffer (also mapped at the identical location in new page tables), which is then free to overwrite target memory (also in new page tables). Note that the proof of concept crashes the gpu fairly badly after it finishes, because I don't bother to setup a replacement first-level ringbuffer. But doesn't mean this couldn't be done if an attacker wanted to be more stealthy. Recommendations: ---------------- The quickest fix would be to disable CONFIG_KGSL_PER_PROCESS_PAGE_TABLE. The setstate memory should also be mapped read-only. And address space randomization could at least make an attack more difficult. Note however that I have observed some pipelining in the CP. You can get away with a couple more commands in the command stream (due to cache or pipelining) after switching to supervisor mode. I strongly suspect there is a window/race where an attacker could overwrite a few dwords of memory after simply putting the IOMMU in bypass mode.