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
