On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote: > 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 mean that this the conversion to void * can be a narrowing conversion, so when printing of kernel pointers is enabled the full physical address may not be displayed. > > 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. The problem is that it is not suitable for printing physical addresses, because they are not pointers. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel