From: Ben Hutchings <ben@decadent.org.uk>
To: Kees Cook <keescook@chromium.org>
Cc: Dave Airlie <airlied@redhat.com>, dri-devel@lists.freedesktop.org
Subject: Re: high_memory address in /proc/dri/*/vma
Date: Tue, 20 Dec 2011 02:18:21 +0000 [thread overview]
Message-ID: <1324347501.2844.111.camel@deadeye> (raw)
In-Reply-To: <CAGXu5jJ07thdR5BC8AhYPuJdyAe=0vePjZEeEWO7LGPbs7iHzg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1816 bytes --]
On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote:
> On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings <ben@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.
> > 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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2011-12-20 2:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-20 0:09 high_memory address in /proc/dri/*/vma Ben Hutchings
2011-12-20 0:14 ` Kees Cook
2011-12-20 2:18 ` Ben Hutchings [this message]
2011-12-20 2:35 ` Kees Cook
2011-12-20 4:23 ` Ben Hutchings
2011-12-20 16:32 ` Daniel Vetter
2011-12-20 17:59 ` Kees Cook
2011-12-20 19:03 ` Ben Hutchings
-- strict thread matches above, loose matches on Subject: below --
2011-12-19 1:23 Ben Hutchings
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1324347501.2844.111.camel@deadeye \
--to=ben@decadent.org.uk \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=keescook@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox