high_memory address in /proc/dri/*/vma

[Kees Cook]

On Tue, Dec 20, 2011 at 8:32 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Tue, Dec 20, 2011 at 12:09:39AM +0000, Ben Hutchings wrote:
>> [Re-sent to the right address, I hope.]
>>
>> Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not
>> leak kernel addresses via /proc/dri/*/vma") you changed the logging of
>> high_memory:
>>
>> -       seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n",
>> +       seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
>>                    atomic_read(&dev->vma_count),
>> -                  high_memory, (u64)virt_to_phys(high_memory));
>> +                  high_memory, (void *)virt_to_phys(high_memory));
>>
>> This doesn't make sense because the physical address may be truncated
>> (in theory at least).
>>
>> I think it would make more sense to make this entire file readable by
>> root only, but I don't know whether anything depends on being able to
>> read it.  Its existence is conditional on DRM_DEBUG_CODE != 0 but that
>> is always true at the moment.
>
> Afaik (and I've done quite some code history checking) the proc files are
> not relied upon by userspace (up to about 10 years back). Patch to kill
> them all is pending and should hit either 3.3 or 3.4.

That works too. :)

-- 
Kees Cook
ChromeOS Security