On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
> 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).
Leaking even a truncated address is still a problem, IMO. Or do you
mean there is some side-effect causing a problem?
> 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.
The kptr_restrict syscall (that controls %pK behavior) has 3 modes,
including one that hides these values even from the root user, so I
would prefer this stays as-is.
Sorry I'm being dense, but what problem is %pK causing here? I'd be
happy to help get it fixed.
-Kees
--
Kees Cook
ChromeOS Security
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
