[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202010021527.DF20CE0@keescook>
Date: Fri, 2 Oct 2020 15:30:30 -0700
From: Kees Cook <keescook@...omium.org>
To: Joe Perches <joe@...ches.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>,
Denis Efremov <efremov@...ux.com>,
Julia Lawall <julia.lawall@...ia.fr>,
Alex Dewar <alex.dewar90@...il.com>,
linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
linux-doc@...r.kernel.org
Subject: Re: [PATCH V3 1/8] sysfs: Add sysfs_emit and sysfs_emit_at to format
sysfs output
On Wed, Sep 30, 2020 at 09:22:19PM -0700, Joe Perches wrote:
> On Wed, 2020-09-30 at 21:17 -0700, Kees Cook wrote:
> > On Wed, Sep 30, 2020 at 01:57:40PM +0200, Greg Kroah-Hartman wrote:
> > > Kees, and Rafael, I don't know if you saw this proposal from Joe for
> > > sysfs files, questions below:
> >
> > I'm a fan. I think the use of sprintf() in sysfs might have been one of
> > my earliest complaints about unsafe code patterns in the kernel. ;)
> []
> > > > + if (WARN(!buf || offset_in_page(buf),
> > > > + "invalid sysfs_emit: buf:%p\n", buf))
>
> The dump_stack() is also going to emit pointers
> so I don't see how it does anything but help
> show where the buffer was. It is hashed...
dump_stack() is going to report symbols and register contents.
I was just pointing out that %p has no value here[1]. The interesting
states are: "was it NULL?" "how offset was it?". Its actual content
won't matter.
-Kees
[1] "New uses of %p should not be added to the kernel"
https://www.kernel.org/doc/html/latest/process/deprecated.html#p-format-specifier
--
Kees Cook
Powered by blists - more mailing lists