high_memory address in /proc/dri/*/vma

[Ben Hutchings]

On Mon, 2011-12-19 at 18:35 -0800, Kees Cook wrote:
> On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings <ben at decadent.org.uk> wrote:
> > On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
> >> On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings <ben at decadent.org.uk> 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.
> 
> Ah-ha, okay, I see what you mean now. This is, as you say, only a
> problem "in theory". Is it worth fixing currently?

I don't know.

> If so, we probably need to add the "K" option to %x in some fashion.

Something like that, yes.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111220/9587f7c1/attachment-0001.pgp>