On Fri, Apr 12, 2013 at 2:15 AM, Mika Kuoppala <mika.kuoppala at linux.intel.com> wrote: > Kees Cook <keescook at chromium.org> writes: > >> On Thu, Apr 11, 2013 at 9:15 AM, Mika Kuoppala >> <mika.kuoppala at linux.intel.com> wrote: >>> Kees Cook <keescook at chromium.org> writes: >>> >>>> On Thu, Apr 11, 2013 at 6:22 AM, Mika Kuoppala >>>> <mika.kuoppala at linux.intel.com> wrote: >>>>> commit 647416f9eefe7699754b01b9fc82758fde83248c >>>>> Author: Kees Cook <keescook at chromium.org> >>>>> Date: Sun Mar 10 14:10:06 2013 -0700 >>>>> >>>>> drm/i915: use simple attribute in debugfs routines >>>>> >>>>> made i915_next_seqno debugfs entry to crop it's output >>>>> if returned value was large enough. Using simple_attr >>>>> will limit the output to 24 bytes. Fix this by returning >>>>> only the value and nothing else. >>>>> >>>>> Cc: Kees Cook <keescook at chromium.org> >>>>> Signed-off-by: Mika Kuoppala <mika.kuoppala at intel.com> >>>> >>>> Oh! Thanks for catching that. What a weird limitation. >>>> >>>> What about max freq, min freq, and wedged? Do those run the risk of >>>> truncation too? >>> >>> max and min freq should be safe, and wedged too on 32bit platforms. >>> But if gpu is declared wedged on host with 64bit atomic_t, >>> it will crop the output. >> >> Should we consider proposing an increase in the size of the simple >> attr buffer? It seems silly to provide an arbitrary format string but >> leave the buffer so small. > > That or dynamic allocation to attr->get_buf. But that would need > extra pass with snprintf and I don't know if that qualifies as 'simple' > anymore. > > I have posted a patch which fixes all i915 debugfs simple attributes > to fit into the simple_attr by removing everything except the fmt to > value. I didn't find any testcases which would rely on preample > being there. That works too. :) If you want, consider them: Acked-by: Kees Cook <keescook at chromium.org> :) Thanks! -Kees -- Kees Cook Chrome OS Security
