[Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Steven Rostedt]

At Kernel Recipes, I talked with some people that have mature
interfaces in the debugfs directory, but they can not access them on
systems that have debugfs disabled. What would be the process to have
these systems move out of debugfs? Should they create their own fs and
be mounted in /sys/kernel, with a dedicated directory if the file system
is enabled in the kernel (I had tracefs do that).

Is this something we should discuss at Maintainers Summit? What is the
process for mature debugfs directories? What's the justification to
have them moved? Is there a better answer for this?

-- Steve

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg KH]

On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
> At Kernel Recipes, I talked with some people that have mature
> interfaces in the debugfs directory, but they can not access them on
> systems that have debugfs disabled. What would be the process to have
> these systems move out of debugfs? Should they create their own fs and
> be mounted in /sys/kernel, with a dedicated directory if the file system
> is enabled in the kernel (I had tracefs do that).
> 
> Is this something we should discuss at Maintainers Summit? What is the
> process for mature debugfs directories? What's the justification to
> have them moved? Is there a better answer for this?

It's a technical topic, so maintainers summit doesn't make sense.

Stuff in debugfs should NEVER be used for anything "real" or anything
other than debugging.  So I would argue that that code needs to be fixed
up now anyway, as most distros are disabling debugfs for the obvious
reasons (and Android is also turning it off).

As for where to put it, it all depends on exactly what it is, and what
it does and who uses it.  So it's almost always a case-by-case basis.

Any specific examples you wish to share of code that needs this?

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg KH]

On Mon, Oct 01, 2018 at 06:18:56PM -0700, Greg KH wrote:
> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
> > At Kernel Recipes, I talked with some people that have mature
> > interfaces in the debugfs directory, but they can not access them on
> > systems that have debugfs disabled. What would be the process to have
> > these systems move out of debugfs? Should they create their own fs and
> > be mounted in /sys/kernel, with a dedicated directory if the file system
> > is enabled in the kernel (I had tracefs do that).
> > 
> > Is this something we should discuss at Maintainers Summit? What is the
> > process for mature debugfs directories? What's the justification to
> > have them moved? Is there a better answer for this?
> 
> It's a technical topic, so maintainers summit doesn't make sense.
> 
> Stuff in debugfs should NEVER be used for anything "real" or anything
> other than debugging.  So I would argue that that code needs to be fixed
> up now anyway, as most distros are disabling debugfs for the obvious
> reasons (and Android is also turning it off).
> 
> As for where to put it, it all depends on exactly what it is, and what
> it does and who uses it.  So it's almost always a case-by-case basis.
> 
> Any specific examples you wish to share of code that needs this?

Oh, and the "process"?  Just do it.  Nothing should be depending on
debugfs for "system functionality"[1], so it should be just fine to move
files around and delete them.

thanks,

greg k-h

[1] There's a whole line of SoCs out there there that ended up putting
the battery measurement logic in a debugfs file, despite us having a
well known and well documented batter/power api already in sysfs.  By
turning debugfs off, all of a sudden your phone has no way to report the
state of the battery.  Fun stuff...

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Steven Rostedt]

On Mon, 1 Oct 2018 18:18:56 -0700
Greg KH <gregkh@linuxfoundation.org> wrote:

> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
> > At Kernel Recipes, I talked with some people that have mature
> > interfaces in the debugfs directory, but they can not access them on
> > systems that have debugfs disabled. What would be the process to have
> > these systems move out of debugfs? Should they create their own fs and
> > be mounted in /sys/kernel, with a dedicated directory if the file system
> > is enabled in the kernel (I had tracefs do that).
> > 
> > Is this something we should discuss at Maintainers Summit? What is the
> > process for mature debugfs directories? What's the justification to
> > have them moved? Is there a better answer for this?  
> 
> It's a technical topic, so maintainers summit doesn't make sense.
> 
> Stuff in debugfs should NEVER be used for anything "real" or anything
> other than debugging.  So I would argue that that code needs to be fixed
> up now anyway, as most distros are disabling debugfs for the obvious
> reasons (and Android is also turning it off).

The funny part is, things used for debugging tend to turn into
something that people want on production systems (tracing,
perf, powertop, etc).

> 
> As for where to put it, it all depends on exactly what it is, and what
> it does and who uses it.  So it's almost always a case-by-case basis.
> 
> Any specific examples you wish to share of code that needs this?
> 

tracefs was one example, but someone was talking to me at Kernel
Recipes and wanted had another directory in debugfs and wanted it out
as it was stable and wanted it exposed when debugfs is turned off.
Unfortunately, this was discussed at an evening event, and I don't
recall the specifics.

As most distros now disable debugfs (great!), perhaps it can be used as
a place to hold interfaces that are under develop, and not worry about
breaking user space, as all distros will have it off, thus no tool
should depend on it.

-- Steve

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Olof Johansson]

On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 1 Oct 2018 18:18:56 -0700
> Greg KH <gregkh@linuxfoundation.org> wrote:
>
> > On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
> > > At Kernel Recipes, I talked with some people that have mature
> > > interfaces in the debugfs directory, but they can not access them on
> > > systems that have debugfs disabled. What would be the process to have
> > > these systems move out of debugfs? Should they create their own fs and
> > > be mounted in /sys/kernel, with a dedicated directory if the file system
> > > is enabled in the kernel (I had tracefs do that).
> > >
> > > Is this something we should discuss at Maintainers Summit? What is the
> > > process for mature debugfs directories? What's the justification to
> > > have them moved? Is there a better answer for this?
> >
> > It's a technical topic, so maintainers summit doesn't make sense.
> >
> > Stuff in debugfs should NEVER be used for anything "real" or anything
> > other than debugging.  So I would argue that that code needs to be fixed
> > up now anyway, as most distros are disabling debugfs for the obvious
> > reasons (and Android is also turning it off).
>
> The funny part is, things used for debugging tend to turn into
> something that people want on production systems (tracing,
> perf, powertop, etc).
>
> >
> > As for where to put it, it all depends on exactly what it is, and what
> > it does and who uses it.  So it's almost always a case-by-case basis.
> >
> > Any specific examples you wish to share of code that needs this?
> >
>
> tracefs was one example, but someone was talking to me at Kernel
> Recipes and wanted had another directory in debugfs and wanted it out
> as it was stable and wanted it exposed when debugfs is turned off.
> Unfortunately, this was discussed at an evening event, and I don't
> recall the specifics.

One really useful criteria for graduating some service to sysfs would
be to have namespaces and security aspects sorted out for it. Being in
debugfs you can ignore all of that.

Having something that containers might want for their own use (say,
for example, some trace functionality) move into sysfs but not being
possible to provide to an unprivileged container seems like things
we'd like to avoid.


-Olof

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Shuah Khan]

On 10/02/2018 08:59 AM, Olof Johansson wrote:
> On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>>
>> On Mon, 1 Oct 2018 18:18:56 -0700
>> Greg KH <gregkh@linuxfoundation.org> wrote:
>>
>>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
>>>> At Kernel Recipes, I talked with some people that have mature
>>>> interfaces in the debugfs directory, but they can not access them on
>>>> systems that have debugfs disabled. What would be the process to have
>>>> these systems move out of debugfs? Should they create their own fs and
>>>> be mounted in /sys/kernel, with a dedicated directory if the file system
>>>> is enabled in the kernel (I had tracefs do that).
>>>>
>>>> Is this something we should discuss at Maintainers Summit? What is the
>>>> process for mature debugfs directories? What's the justification to
>>>> have them moved? Is there a better answer for this?
>>>
>>> It's a technical topic, so maintainers summit doesn't make sense.
>>>
>>> Stuff in debugfs should NEVER be used for anything "real" or anything
>>> other than debugging.  So I would argue that that code needs to be fixed
>>> up now anyway, as most distros are disabling debugfs for the obvious
>>> reasons (and Android is also turning it off).
>>
>> The funny part is, things used for debugging tend to turn into
>> something that people want on production systems (tracing,
>> perf, powertop, etc).
>>
>>>
>>> As for where to put it, it all depends on exactly what it is, and what
>>> it does and who uses it.  So it's almost always a case-by-case basis.
>>>
>>> Any specific examples you wish to share of code that needs this?
>>>
>>
>> tracefs was one example, but someone was talking to me at Kernel
>> Recipes and wanted had another directory in debugfs and wanted it out
>> as it was stable and wanted it exposed when debugfs is turned off.
>> Unfortunately, this was discussed at an evening event, and I don't
>> recall the specifics.
> 
> One really useful criteria for graduating some service to sysfs would
> be to have namespaces and security aspects sorted out for it. Being in
> debugfs you can ignore all of that.

Yes. Moving to debugfs service to sysfs would make it more secure. However,
security is important even if it stays in debugfs.

I don't believe that is safe to have a lower security bar for dbugfs
interfaces. Not all distros disable debugfs and if debugfs becomes
vulnerability, it would become target on distros that don't disable.

> 
> Having something that containers might want for their own use (say,
> for example, some trace functionality) move into sysfs but not being
> possible to provide to an unprivileged container seems like things
> we'd like to avoid.
> 

We still have to be concerned about restricting the scope of the sysfs
to containers and we run into namespace issues that sysfs being visible
to other containers.

I am dealing one such driver that is being used in container space and
its namespace not being restricted to container scope.

thanks,
-- Shuah


> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman]

On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:
> On 10/02/2018 08:59 AM, Olof Johansson wrote:
> > On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >>
> >> On Mon, 1 Oct 2018 18:18:56 -0700
> >> Greg KH <gregkh@linuxfoundation.org> wrote:
> >>
> >>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
> >>>> At Kernel Recipes, I talked with some people that have mature
> >>>> interfaces in the debugfs directory, but they can not access them on
> >>>> systems that have debugfs disabled. What would be the process to have
> >>>> these systems move out of debugfs? Should they create their own fs and
> >>>> be mounted in /sys/kernel, with a dedicated directory if the file system
> >>>> is enabled in the kernel (I had tracefs do that).
> >>>>
> >>>> Is this something we should discuss at Maintainers Summit? What is the
> >>>> process for mature debugfs directories? What's the justification to
> >>>> have them moved? Is there a better answer for this?
> >>>
> >>> It's a technical topic, so maintainers summit doesn't make sense.
> >>>
> >>> Stuff in debugfs should NEVER be used for anything "real" or anything
> >>> other than debugging.  So I would argue that that code needs to be fixed
> >>> up now anyway, as most distros are disabling debugfs for the obvious
> >>> reasons (and Android is also turning it off).
> >>
> >> The funny part is, things used for debugging tend to turn into
> >> something that people want on production systems (tracing,
> >> perf, powertop, etc).
> >>
> >>>
> >>> As for where to put it, it all depends on exactly what it is, and what
> >>> it does and who uses it.  So it's almost always a case-by-case basis.
> >>>
> >>> Any specific examples you wish to share of code that needs this?
> >>>
> >>
> >> tracefs was one example, but someone was talking to me at Kernel
> >> Recipes and wanted had another directory in debugfs and wanted it out
> >> as it was stable and wanted it exposed when debugfs is turned off.
> >> Unfortunately, this was discussed at an evening event, and I don't
> >> recall the specifics.
> > 
> > One really useful criteria for graduating some service to sysfs would
> > be to have namespaces and security aspects sorted out for it. Being in
> > debugfs you can ignore all of that.
> 
> Yes. Moving to debugfs service to sysfs would make it more secure. However,
> security is important even if it stays in debugfs.
> 
> I don't believe that is safe to have a lower security bar for dbugfs
> interfaces. Not all distros disable debugfs and if debugfs becomes
> vulnerability, it would become target on distros that don't disable.

Until about 8 months or so ago, maybe a year, debugfs was totally
insecure and it was very trivial to use to crash the kernel.  Which is
why it is a good idea to lock it down and not mount it on "untrusted"
systems.

The bar for "security" on debugfs is very low, if not existant, as it
should only be for debugging.  Yes, it is very easy to use (by design),
and so people like to abuse it for things they would have to take more
work to "get right" like sysfs or other filesystem-like interfaces.

And that's ok, again, it is only for debugging, don't trust it for
anything else please.

> > Having something that containers might want for their own use (say,
> > for example, some trace functionality) move into sysfs but not being
> > possible to provide to an unprivileged container seems like things
> > we'd like to avoid.
> > 
> 
> We still have to be concerned about restricting the scope of the sysfs
> to containers and we run into namespace issues that sysfs being visible
> to other containers.
> 
> I am dealing one such driver that is being used in container space and
> its namespace not being restricted to container scope.

The kernel doesn't know about "containers" :)

sysfs does have namespacing, if you really want to use it.  Networking
does, so you can use that as an example.  But most driver subsystems do
not have namespaces, nor, I would argue, should they have.

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman]

On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
> On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:
> > On 10/02/2018 08:59 AM, Olof Johansson wrote:
> > > On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> > >>
> > >> On Mon, 1 Oct 2018 18:18:56 -0700
> > >> Greg KH <gregkh@linuxfoundation.org> wrote:
> > >>
> > >>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:
> > >>>> At Kernel Recipes, I talked with some people that have mature
> > >>>> interfaces in the debugfs directory, but they can not access them on
> > >>>> systems that have debugfs disabled. What would be the process to have
> > >>>> these systems move out of debugfs? Should they create their own fs and
> > >>>> be mounted in /sys/kernel, with a dedicated directory if the file system
> > >>>> is enabled in the kernel (I had tracefs do that).
> > >>>>
> > >>>> Is this something we should discuss at Maintainers Summit? What is the
> > >>>> process for mature debugfs directories? What's the justification to
> > >>>> have them moved? Is there a better answer for this?
> > >>>
> > >>> It's a technical topic, so maintainers summit doesn't make sense.
> > >>>
> > >>> Stuff in debugfs should NEVER be used for anything "real" or anything
> > >>> other than debugging.  So I would argue that that code needs to be fixed
> > >>> up now anyway, as most distros are disabling debugfs for the obvious
> > >>> reasons (and Android is also turning it off).
> > >>
> > >> The funny part is, things used for debugging tend to turn into
> > >> something that people want on production systems (tracing,
> > >> perf, powertop, etc).
> > >>
> > >>>
> > >>> As for where to put it, it all depends on exactly what it is, and what
> > >>> it does and who uses it.  So it's almost always a case-by-case basis.
> > >>>
> > >>> Any specific examples you wish to share of code that needs this?
> > >>>
> > >>
> > >> tracefs was one example, but someone was talking to me at Kernel
> > >> Recipes and wanted had another directory in debugfs and wanted it out
> > >> as it was stable and wanted it exposed when debugfs is turned off.
> > >> Unfortunately, this was discussed at an evening event, and I don't
> > >> recall the specifics.
> > > 
> > > One really useful criteria for graduating some service to sysfs would
> > > be to have namespaces and security aspects sorted out for it. Being in
> > > debugfs you can ignore all of that.
> > 
> > Yes. Moving to debugfs service to sysfs would make it more secure. However,
> > security is important even if it stays in debugfs.
> > 
> > I don't believe that is safe to have a lower security bar for dbugfs
> > interfaces. Not all distros disable debugfs and if debugfs becomes
> > vulnerability, it would become target on distros that don't disable.
> 
> Until about 8 months or so ago, maybe a year, debugfs was totally
> insecure and it was very trivial to use to crash the kernel.  Which is
> why it is a good idea to lock it down and not mount it on "untrusted"
> systems.

Based on a discussion on another thread on a public list, there are
still remaining issues with debugfs that can cause major problems.  So
no one should ever mount it on an untrusted system still.

It is getting better, but the issues are tough to resolve, give us
another year or so :)

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Mauro Carvalho Chehab]

Em Tue, 2 Oct 2018 09:30:01 -0700
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:

> On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:  
> > > On 10/02/2018 08:59 AM, Olof Johansson wrote:  
> > > > On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
> > > >>
> > > >> On Mon, 1 Oct 2018 18:18:56 -0700
> > > >> Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >>  
> > > >>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:  
> > > >>>> At Kernel Recipes, I talked with some people that have mature
> > > >>>> interfaces in the debugfs directory, but they can not access them on
> > > >>>> systems that have debugfs disabled. What would be the process to have
> > > >>>> these systems move out of debugfs? Should they create their own fs and
> > > >>>> be mounted in /sys/kernel, with a dedicated directory if the file system
> > > >>>> is enabled in the kernel (I had tracefs do that).
> > > >>>>
> > > >>>> Is this something we should discuss at Maintainers Summit? What is the
> > > >>>> process for mature debugfs directories? What's the justification to
> > > >>>> have them moved? Is there a better answer for this?  
> > > >>>
> > > >>> It's a technical topic, so maintainers summit doesn't make sense.
> > > >>>
> > > >>> Stuff in debugfs should NEVER be used for anything "real" or anything
> > > >>> other than debugging.  So I would argue that that code needs to be fixed
> > > >>> up now anyway, as most distros are disabling debugfs for the obvious
> > > >>> reasons (and Android is also turning it off).  
> > > >>
> > > >> The funny part is, things used for debugging tend to turn into
> > > >> something that people want on production systems (tracing,
> > > >> perf, powertop, etc).
> > > >>  
> > > >>>
> > > >>> As for where to put it, it all depends on exactly what it is, and what
> > > >>> it does and who uses it.  So it's almost always a case-by-case basis.
> > > >>>
> > > >>> Any specific examples you wish to share of code that needs this?
> > > >>>  
> > > >>
> > > >> tracefs was one example, but someone was talking to me at Kernel
> > > >> Recipes and wanted had another directory in debugfs and wanted it out
> > > >> as it was stable and wanted it exposed when debugfs is turned off.
> > > >> Unfortunately, this was discussed at an evening event, and I don't
> > > >> recall the specifics.  
> > > > 
> > > > One really useful criteria for graduating some service to sysfs would
> > > > be to have namespaces and security aspects sorted out for it. Being in
> > > > debugfs you can ignore all of that.  
> > > 
> > > Yes. Moving to debugfs service to sysfs would make it more secure. However,
> > > security is important even if it stays in debugfs.
> > > 
> > > I don't believe that is safe to have a lower security bar for dbugfs
> > > interfaces. Not all distros disable debugfs and if debugfs becomes
> > > vulnerability, it would become target on distros that don't disable.  
> > 
> > Until about 8 months or so ago, maybe a year, debugfs was totally
> > insecure and it was very trivial to use to crash the kernel.  Which is
> > why it is a good idea to lock it down and not mount it on "untrusted"
> > systems.  
> 
> Based on a discussion on another thread on a public list, there are
> still remaining issues with debugfs that can cause major problems.  So
> no one should ever mount it on an untrusted system still.
> 
> It is getting better, but the issues are tough to resolve, give us
> another year or so :)

Even if it won't be possible to crash the Kernel or escalate
privileges, I suspect that several stuff in debugfs should never
be enabled on production systems, as they may reveal things like
memory addresses and other stuff that could be used to help someone
to crack a system.

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Shuah Khan]

On 10/02/2018 03:37 PM, Mauro Carvalho Chehab wrote:
> Em Tue, 2 Oct 2018 09:30:01 -0700
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> 
>> On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
>>> On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:  
>>>> On 10/02/2018 08:59 AM, Olof Johansson wrote:  
>>>>> On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
>>>>>>
>>>>>> On Mon, 1 Oct 2018 18:18:56 -0700
>>>>>> Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>>>  
>>>>>>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:  
>>>>>>>> At Kernel Recipes, I talked with some people that have mature
>>>>>>>> interfaces in the debugfs directory, but they can not access them on
>>>>>>>> systems that have debugfs disabled. What would be the process to have
>>>>>>>> these systems move out of debugfs? Should they create their own fs and
>>>>>>>> be mounted in /sys/kernel, with a dedicated directory if the file system
>>>>>>>> is enabled in the kernel (I had tracefs do that).
>>>>>>>>
>>>>>>>> Is this something we should discuss at Maintainers Summit? What is the
>>>>>>>> process for mature debugfs directories? What's the justification to
>>>>>>>> have them moved? Is there a better answer for this?  
>>>>>>>
>>>>>>> It's a technical topic, so maintainers summit doesn't make sense.
>>>>>>>
>>>>>>> Stuff in debugfs should NEVER be used for anything "real" or anything
>>>>>>> other than debugging.  So I would argue that that code needs to be fixed
>>>>>>> up now anyway, as most distros are disabling debugfs for the obvious
>>>>>>> reasons (and Android is also turning it off).  
>>>>>>
>>>>>> The funny part is, things used for debugging tend to turn into
>>>>>> something that people want on production systems (tracing,
>>>>>> perf, powertop, etc).
>>>>>>  
>>>>>>>
>>>>>>> As for where to put it, it all depends on exactly what it is, and what
>>>>>>> it does and who uses it.  So it's almost always a case-by-case basis.
>>>>>>>
>>>>>>> Any specific examples you wish to share of code that needs this?
>>>>>>>  
>>>>>>
>>>>>> tracefs was one example, but someone was talking to me at Kernel
>>>>>> Recipes and wanted had another directory in debugfs and wanted it out
>>>>>> as it was stable and wanted it exposed when debugfs is turned off.
>>>>>> Unfortunately, this was discussed at an evening event, and I don't
>>>>>> recall the specifics.  
>>>>>
>>>>> One really useful criteria for graduating some service to sysfs would
>>>>> be to have namespaces and security aspects sorted out for it. Being in
>>>>> debugfs you can ignore all of that.  
>>>>
>>>> Yes. Moving to debugfs service to sysfs would make it more secure. However,
>>>> security is important even if it stays in debugfs.
>>>>
>>>> I don't believe that is safe to have a lower security bar for dbugfs
>>>> interfaces. Not all distros disable debugfs and if debugfs becomes
>>>> vulnerability, it would become target on distros that don't disable.  
>>>
>>> Until about 8 months or so ago, maybe a year, debugfs was totally
>>> insecure and it was very trivial to use to crash the kernel.  Which is
>>> why it is a good idea to lock it down and not mount it on "untrusted"
>>> systems.  
>>
>> Based on a discussion on another thread on a public list, there are
>> still remaining issues with debugfs that can cause major problems.  So
>> no one should ever mount it on an untrusted system still.
>>
>> It is getting better, but the issues are tough to resolve, give us
>> another year or so :)
> 
> Even if it won't be possible to crash the Kernel or escalate
> privileges, I suspect that several stuff in debugfs should never
> be enabled on production systems, as they may reveal things like
> memory addresses and other stuff that could be used to help someone
> to crack a system.
> 

Unfortunately distros enable DEBUG_FS. I checked a couple of distro configs.

One popular distro enables:

CONFIG_BLK_DEBUG_FS=y
CONFIG_KVM_DEBUG_FS=y
CONFIG_DEBUG_FS=y

Another one enables:

CONFIG_BLK_DEBUG_FS=y
CONFIG_DEBUG_FS=y

It looks to me that this message need to be communicated widely so distros can
tighten things up.

thanks,
-- Shuah

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman]

On Tue, Oct 02, 2018 at 03:57:30PM -0600, Shuah Khan wrote:
> On 10/02/2018 03:37 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 2 Oct 2018 09:30:01 -0700
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> > 
> >> On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
> >>> On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:  
> >>>> On 10/02/2018 08:59 AM, Olof Johansson wrote:  
> >>>>> On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
> >>>>>>
> >>>>>> On Mon, 1 Oct 2018 18:18:56 -0700
> >>>>>> Greg KH <gregkh@linuxfoundation.org> wrote:
> >>>>>>  
> >>>>>>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:  
> >>>>>>>> At Kernel Recipes, I talked with some people that have mature
> >>>>>>>> interfaces in the debugfs directory, but they can not access them on
> >>>>>>>> systems that have debugfs disabled. What would be the process to have
> >>>>>>>> these systems move out of debugfs? Should they create their own fs and
> >>>>>>>> be mounted in /sys/kernel, with a dedicated directory if the file system
> >>>>>>>> is enabled in the kernel (I had tracefs do that).
> >>>>>>>>
> >>>>>>>> Is this something we should discuss at Maintainers Summit? What is the
> >>>>>>>> process for mature debugfs directories? What's the justification to
> >>>>>>>> have them moved? Is there a better answer for this?  
> >>>>>>>
> >>>>>>> It's a technical topic, so maintainers summit doesn't make sense.
> >>>>>>>
> >>>>>>> Stuff in debugfs should NEVER be used for anything "real" or anything
> >>>>>>> other than debugging.  So I would argue that that code needs to be fixed
> >>>>>>> up now anyway, as most distros are disabling debugfs for the obvious
> >>>>>>> reasons (and Android is also turning it off).  
> >>>>>>
> >>>>>> The funny part is, things used for debugging tend to turn into
> >>>>>> something that people want on production systems (tracing,
> >>>>>> perf, powertop, etc).
> >>>>>>  
> >>>>>>>
> >>>>>>> As for where to put it, it all depends on exactly what it is, and what
> >>>>>>> it does and who uses it.  So it's almost always a case-by-case basis.
> >>>>>>>
> >>>>>>> Any specific examples you wish to share of code that needs this?
> >>>>>>>  
> >>>>>>
> >>>>>> tracefs was one example, but someone was talking to me at Kernel
> >>>>>> Recipes and wanted had another directory in debugfs and wanted it out
> >>>>>> as it was stable and wanted it exposed when debugfs is turned off.
> >>>>>> Unfortunately, this was discussed at an evening event, and I don't
> >>>>>> recall the specifics.  
> >>>>>
> >>>>> One really useful criteria for graduating some service to sysfs would
> >>>>> be to have namespaces and security aspects sorted out for it. Being in
> >>>>> debugfs you can ignore all of that.  
> >>>>
> >>>> Yes. Moving to debugfs service to sysfs would make it more secure. However,
> >>>> security is important even if it stays in debugfs.
> >>>>
> >>>> I don't believe that is safe to have a lower security bar for dbugfs
> >>>> interfaces. Not all distros disable debugfs and if debugfs becomes
> >>>> vulnerability, it would become target on distros that don't disable.  
> >>>
> >>> Until about 8 months or so ago, maybe a year, debugfs was totally
> >>> insecure and it was very trivial to use to crash the kernel.  Which is
> >>> why it is a good idea to lock it down and not mount it on "untrusted"
> >>> systems.  
> >>
> >> Based on a discussion on another thread on a public list, there are
> >> still remaining issues with debugfs that can cause major problems.  So
> >> no one should ever mount it on an untrusted system still.
> >>
> >> It is getting better, but the issues are tough to resolve, give us
> >> another year or so :)
> > 
> > Even if it won't be possible to crash the Kernel or escalate
> > privileges, I suspect that several stuff in debugfs should never
> > be enabled on production systems, as they may reveal things like
> > memory addresses and other stuff that could be used to help someone
> > to crack a system.
> > 
> 
> Unfortunately distros enable DEBUG_FS. I checked a couple of distro configs.
> 
> One popular distro enables:
> 
> CONFIG_BLK_DEBUG_FS=y
> CONFIG_KVM_DEBUG_FS=y
> CONFIG_DEBUG_FS=y
> 
> Another one enables:
> 
> CONFIG_BLK_DEBUG_FS=y
> CONFIG_DEBUG_FS=y
> 
> It looks to me that this message need to be communicated widely so distros can
> tighten things up.

Luckily debugfs was made "root only by default" a while ago, to help
mitigate this problem.  So while it is present on a number of distros,
the "attack surface" is greatly reduced.

That being said, I bet those distros can drop those config options and
be fine.

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Jan Kara]

On Tue 02-10-18 15:22:38, Greg Kroah-Hartman wrote:
> On Tue, Oct 02, 2018 at 03:57:30PM -0600, Shuah Khan wrote:
> > On 10/02/2018 03:37 PM, Mauro Carvalho Chehab wrote:
> > > Em Tue, 2 Oct 2018 09:30:01 -0700
> > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
> > > 
> > >> On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
> > >>> On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:  
> > >>>> On 10/02/2018 08:59 AM, Olof Johansson wrote:  
> > >>>>> On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
> > >>>>>>
> > >>>>>> On Mon, 1 Oct 2018 18:18:56 -0700
> > >>>>>> Greg KH <gregkh@linuxfoundation.org> wrote:
> > >>>>>>  
> > >>>>>>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:  
> > >>>>>>>> At Kernel Recipes, I talked with some people that have mature
> > >>>>>>>> interfaces in the debugfs directory, but they can not access them on
> > >>>>>>>> systems that have debugfs disabled. What would be the process to have
> > >>>>>>>> these systems move out of debugfs? Should they create their own fs and
> > >>>>>>>> be mounted in /sys/kernel, with a dedicated directory if the file system
> > >>>>>>>> is enabled in the kernel (I had tracefs do that).
> > >>>>>>>>
> > >>>>>>>> Is this something we should discuss at Maintainers Summit? What is the
> > >>>>>>>> process for mature debugfs directories? What's the justification to
> > >>>>>>>> have them moved? Is there a better answer for this?  
> > >>>>>>>
> > >>>>>>> It's a technical topic, so maintainers summit doesn't make sense.
> > >>>>>>>
> > >>>>>>> Stuff in debugfs should NEVER be used for anything "real" or anything
> > >>>>>>> other than debugging.  So I would argue that that code needs to be fixed
> > >>>>>>> up now anyway, as most distros are disabling debugfs for the obvious
> > >>>>>>> reasons (and Android is also turning it off).  
> > >>>>>>
> > >>>>>> The funny part is, things used for debugging tend to turn into
> > >>>>>> something that people want on production systems (tracing,
> > >>>>>> perf, powertop, etc).
> > >>>>>>  
> > >>>>>>>
> > >>>>>>> As for where to put it, it all depends on exactly what it is, and what
> > >>>>>>> it does and who uses it.  So it's almost always a case-by-case basis.
> > >>>>>>>
> > >>>>>>> Any specific examples you wish to share of code that needs this?
> > >>>>>>>  
> > >>>>>>
> > >>>>>> tracefs was one example, but someone was talking to me at Kernel
> > >>>>>> Recipes and wanted had another directory in debugfs and wanted it out
> > >>>>>> as it was stable and wanted it exposed when debugfs is turned off.
> > >>>>>> Unfortunately, this was discussed at an evening event, and I don't
> > >>>>>> recall the specifics.  
> > >>>>>
> > >>>>> One really useful criteria for graduating some service to sysfs would
> > >>>>> be to have namespaces and security aspects sorted out for it. Being in
> > >>>>> debugfs you can ignore all of that.  
> > >>>>
> > >>>> Yes. Moving to debugfs service to sysfs would make it more secure. However,
> > >>>> security is important even if it stays in debugfs.
> > >>>>
> > >>>> I don't believe that is safe to have a lower security bar for dbugfs
> > >>>> interfaces. Not all distros disable debugfs and if debugfs becomes
> > >>>> vulnerability, it would become target on distros that don't disable.  
> > >>>
> > >>> Until about 8 months or so ago, maybe a year, debugfs was totally
> > >>> insecure and it was very trivial to use to crash the kernel.  Which is
> > >>> why it is a good idea to lock it down and not mount it on "untrusted"
> > >>> systems.  
> > >>
> > >> Based on a discussion on another thread on a public list, there are
> > >> still remaining issues with debugfs that can cause major problems.  So
> > >> no one should ever mount it on an untrusted system still.
> > >>
> > >> It is getting better, but the issues are tough to resolve, give us
> > >> another year or so :)
> > > 
> > > Even if it won't be possible to crash the Kernel or escalate
> > > privileges, I suspect that several stuff in debugfs should never
> > > be enabled on production systems, as they may reveal things like
> > > memory addresses and other stuff that could be used to help someone
> > > to crack a system.
> > > 
> > 
> > Unfortunately distros enable DEBUG_FS. I checked a couple of distro configs.
> > 
> > One popular distro enables:
> > 
> > CONFIG_BLK_DEBUG_FS=y
> > CONFIG_KVM_DEBUG_FS=y
> > CONFIG_DEBUG_FS=y
> > 
> > Another one enables:
> > 
> > CONFIG_BLK_DEBUG_FS=y
> > CONFIG_DEBUG_FS=y
> > 
> > It looks to me that this message need to be communicated widely so distros can
> > tighten things up.
> 
> Luckily debugfs was made "root only by default" a while ago, to help
> mitigate this problem.  So while it is present on a number of distros,
> the "attack surface" is greatly reduced.
> 
> That being said, I bet those distros can drop those config options and
> be fine.

Not really. We need those configs to be enabled to be able to troubleshoot
customer's problems - e.g., asking customer to enable some trace points or
show some stats from debugfs is pretty common...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman]

On Wed, Oct 03, 2018 at 02:59:16PM +0200, Jan Kara wrote:
> On Tue 02-10-18 15:22:38, Greg Kroah-Hartman wrote:
> > Luckily debugfs was made "root only by default" a while ago, to help
> > mitigate this problem.  So while it is present on a number of distros,
> > the "attack surface" is greatly reduced.
> > 
> > That being said, I bet those distros can drop those config options and
> > be fine.
> 
> Not really. We need those configs to be enabled to be able to troubleshoot
> customer's problems - e.g., asking customer to enable some trace points or
> show some stats from debugfs is pretty common...

trace points should not be in debugfs.  And what stats are in debugfs
that are not availble in other tools?  If you rely on them, shouldn't we
move them to a "stable" location so that they can always be accessed?

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Jiri Kosina]

On Wed, 3 Oct 2018, Greg Kroah-Hartman wrote:

> > Not really. We need those configs to be enabled to be able to troubleshoot
> > customer's problems - e.g., asking customer to enable some trace points or
> > show some stats from debugfs is pretty common...
> 
> trace points should not be in debugfs.  And what stats are in debugfs
> that are not availble in other tools?  If you rely on them, shouldn't we
> move them to a "stable" location so that they can always be accessed?

So I for example quite often make use of the HID debugfs entries both for 
reading the descriptor, and also for analyzing the parsed events (which 
appear there as well).

Surely it can be moved whereever else (where?), but it seems to fit to 
debugfs (it's used solely to debug dysfunctional devices / linux with 
those devices), and provides exactly the data you need from the owner of 
the system to provide in order to be able to debug remotely.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman]

On Wed, Oct 03, 2018 at 03:44:37PM +0200, Jiri Kosina wrote:
> On Wed, 3 Oct 2018, Greg Kroah-Hartman wrote:
> 
> > > Not really. We need those configs to be enabled to be able to troubleshoot
> > > customer's problems - e.g., asking customer to enable some trace points or
> > > show some stats from debugfs is pretty common...
> > 
> > trace points should not be in debugfs.  And what stats are in debugfs
> > that are not availble in other tools?  If you rely on them, shouldn't we
> > move them to a "stable" location so that they can always be accessed?
> 
> So I for example quite often make use of the HID debugfs entries both for 
> reading the descriptor, and also for analyzing the parsed events (which 
> appear there as well).

for descriptors, both usb and pci expose them through other means that
are always present, perhaps you want to do the same thing for hid?

> Surely it can be moved whereever else (where?), but it seems to fit to 
> debugfs (it's used solely to debug dysfunctional devices / linux with 
> those devices), and provides exactly the data you need from the owner of 
> the system to provide in order to be able to debug remotely.

hidfs might be needed to match usbfs :)

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Greg Kroah-Hartman]

On Wed, Oct 03, 2018 at 07:32:33AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Oct 03, 2018 at 03:44:37PM +0200, Jiri Kosina wrote:
> > On Wed, 3 Oct 2018, Greg Kroah-Hartman wrote:
> > 
> > > > Not really. We need those configs to be enabled to be able to troubleshoot
> > > > customer's problems - e.g., asking customer to enable some trace points or
> > > > show some stats from debugfs is pretty common...
> > > 
> > > trace points should not be in debugfs.  And what stats are in debugfs
> > > that are not availble in other tools?  If you rely on them, shouldn't we
> > > move them to a "stable" location so that they can always be accessed?
> > 
> > So I for example quite often make use of the HID debugfs entries both for 
> > reading the descriptor, and also for analyzing the parsed events (which 
> > appear there as well).
> 
> for descriptors, both usb and pci expose them through other means that
> are always present, perhaps you want to do the same thing for hid?
> 
> > Surely it can be moved whereever else (where?), but it seems to fit to 
> > debugfs (it's used solely to debug dysfunctional devices / linux with 
> > those devices), and provides exactly the data you need from the owner of 
> > the system to provide in order to be able to debug remotely.
> 
> hidfs might be needed to match usbfs :)

Why not put the raw descriptors in sysfs?  That's what pci and usb do,
there's no reason you can't do the same here.  You already have a sysfs
device.  Oh wait, you do, 'report_descriptor' right?  Why do you also
need it in debugfs?

thanks,

greg k-h

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Jiri Kosina]

On Wed, 3 Oct 2018, Greg Kroah-Hartman wrote:

> Why not put the raw descriptors in sysfs?  That's what pci and usb do,
> there's no reason you can't do the same here.  You already have a sysfs
> device.  Oh wait, you do, 'report_descriptor' right?  Why do you also
> need it in debugfs?

Those are actually two different things -- the one in sysfs is verbatim 
(binary) as has been read from device, but the one in debugfs is actually 
showing how in-kernel parser has understood what came out of the device. 
Which is not necessarily the same thing :) 

Also it's rather verbose, with a lot of strings etc., not sure whether 
you'd want to see that in sysfs.

With 'events' in hid debugfs, it's a similar story really (except it 
doesn't currently have sysfs counterpart at all, as that'd basically just 
be showing raw data as coming from the device).

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Jan Kara]

On Wed 03-10-18 06:40:12, Greg Kroah-Hartman wrote:
> On Wed, Oct 03, 2018 at 02:59:16PM +0200, Jan Kara wrote:
> > On Tue 02-10-18 15:22:38, Greg Kroah-Hartman wrote:
> > > Luckily debugfs was made "root only by default" a while ago, to help
> > > mitigate this problem.  So while it is present on a number of distros,
> > > the "attack surface" is greatly reduced.
> > > 
> > > That being said, I bet those distros can drop those config options and
> > > be fine.
> > 
> > Not really. We need those configs to be enabled to be able to troubleshoot
> > customer's problems - e.g., asking customer to enable some trace points or
> > show some stats from debugfs is pretty common...
> 
> trace points should not be in debugfs.  And what stats are in debugfs
> that are not availble in other tools?  If you rely on them, shouldn't we
> move them to a "stable" location so that they can always be accessed?

I personally use e.g. stats under bdi/ directory. And I agree with Jiri
that these things are usually only useful when debugging problems so they
seem to match debugfs purpose rather well. We would not even need debugfs
*mounted* all the time I guess (but then what's the difference between
root-only access currently enforced and not having it mounted, right). But
we do need to have it compiled into the kernel...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Takashi Iwai]

On Wed, 03 Oct 2018 16:53:51 +0200,
Jan Kara wrote:
> 
> On Wed 03-10-18 06:40:12, Greg Kroah-Hartman wrote:
> > On Wed, Oct 03, 2018 at 02:59:16PM +0200, Jan Kara wrote:
> > > On Tue 02-10-18 15:22:38, Greg Kroah-Hartman wrote:
> > > > Luckily debugfs was made "root only by default" a while ago, to help
> > > > mitigate this problem.  So while it is present on a number of distros,
> > > > the "attack surface" is greatly reduced.
> > > > 
> > > > That being said, I bet those distros can drop those config options and
> > > > be fine.
> > > 
> > > Not really. We need those configs to be enabled to be able to troubleshoot
> > > customer's problems - e.g., asking customer to enable some trace points or
> > > show some stats from debugfs is pretty common...
> > 
> > trace points should not be in debugfs.  And what stats are in debugfs
> > that are not availble in other tools?  If you rely on them, shouldn't we
> > move them to a "stable" location so that they can always be accessed?
> 
> I personally use e.g. stats under bdi/ directory. And I agree with Jiri
> that these things are usually only useful when debugging problems so they
> seem to match debugfs purpose rather well. We would not even need debugfs
> *mounted* all the time I guess (but then what's the difference between
> root-only access currently enforced and not having it mounted, right). But
> we do need to have it compiled into the kernel...

And I think the problem is that debugfs is mounted as default on our
systems.  If it's only for debugging purpose, it should be without
mounted for the normal usages.

Of course, the per-default mount is handier for debugging, and it's
easier for developers to gather the information.  But this can be done
also manually via a debug script like our supportconfig, too.

Actually, we'd *love* to have the capability of gathering debug data
on the production system, too, so disabling debugfs build is likely
no-go.  But disabling the mount is a different story, I guess.


thanks,

Takashi

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Shuah Khan]

On 10/03/2018 06:59 AM, Jan Kara wrote:
> On Tue 02-10-18 15:22:38, Greg Kroah-Hartman wrote:
>> On Tue, Oct 02, 2018 at 03:57:30PM -0600, Shuah Khan wrote:
>>> On 10/02/2018 03:37 PM, Mauro Carvalho Chehab wrote:
>>>> Em Tue, 2 Oct 2018 09:30:01 -0700
>>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:
>>>>
>>>>> On Tue, Oct 02, 2018 at 09:17:30AM -0700, Greg Kroah-Hartman wrote:
>>>>>> On Tue, Oct 02, 2018 at 10:00:29AM -0600, Shuah Khan wrote:  
>>>>>>> On 10/02/2018 08:59 AM, Olof Johansson wrote:  
>>>>>>>> On Tue, Oct 2, 2018 at 6:07 AM Steven Rostedt <rostedt@goodmis.org> wrote:  
>>>>>>>>>
>>>>>>>>> On Mon, 1 Oct 2018 18:18:56 -0700
>>>>>>>>> Greg KH <gregkh@linuxfoundation.org> wrote:
>>>>>>>>>  
>>>>>>>>>> On Mon, Oct 01, 2018 at 02:04:02PM -0400, Steven Rostedt wrote:  
>>>>>>>>>>> At Kernel Recipes, I talked with some people that have mature
>>>>>>>>>>> interfaces in the debugfs directory, but they can not access them on
>>>>>>>>>>> systems that have debugfs disabled. What would be the process to have
>>>>>>>>>>> these systems move out of debugfs? Should they create their own fs and
>>>>>>>>>>> be mounted in /sys/kernel, with a dedicated directory if the file system
>>>>>>>>>>> is enabled in the kernel (I had tracefs do that).
>>>>>>>>>>>
>>>>>>>>>>> Is this something we should discuss at Maintainers Summit? What is the
>>>>>>>>>>> process for mature debugfs directories? What's the justification to
>>>>>>>>>>> have them moved? Is there a better answer for this?  
>>>>>>>>>>
>>>>>>>>>> It's a technical topic, so maintainers summit doesn't make sense.
>>>>>>>>>>
>>>>>>>>>> Stuff in debugfs should NEVER be used for anything "real" or anything
>>>>>>>>>> other than debugging.  So I would argue that that code needs to be fixed
>>>>>>>>>> up now anyway, as most distros are disabling debugfs for the obvious
>>>>>>>>>> reasons (and Android is also turning it off).  
>>>>>>>>>
>>>>>>>>> The funny part is, things used for debugging tend to turn into
>>>>>>>>> something that people want on production systems (tracing,
>>>>>>>>> perf, powertop, etc).
>>>>>>>>>  
>>>>>>>>>>
>>>>>>>>>> As for where to put it, it all depends on exactly what it is, and what
>>>>>>>>>> it does and who uses it.  So it's almost always a case-by-case basis.
>>>>>>>>>>
>>>>>>>>>> Any specific examples you wish to share of code that needs this?
>>>>>>>>>>  
>>>>>>>>>
>>>>>>>>> tracefs was one example, but someone was talking to me at Kernel
>>>>>>>>> Recipes and wanted had another directory in debugfs and wanted it out
>>>>>>>>> as it was stable and wanted it exposed when debugfs is turned off.
>>>>>>>>> Unfortunately, this was discussed at an evening event, and I don't
>>>>>>>>> recall the specifics.  
>>>>>>>>
>>>>>>>> One really useful criteria for graduating some service to sysfs would
>>>>>>>> be to have namespaces and security aspects sorted out for it. Being in
>>>>>>>> debugfs you can ignore all of that.  
>>>>>>>
>>>>>>> Yes. Moving to debugfs service to sysfs would make it more secure. However,
>>>>>>> security is important even if it stays in debugfs.
>>>>>>>
>>>>>>> I don't believe that is safe to have a lower security bar for dbugfs
>>>>>>> interfaces. Not all distros disable debugfs and if debugfs becomes
>>>>>>> vulnerability, it would become target on distros that don't disable.  
>>>>>>
>>>>>> Until about 8 months or so ago, maybe a year, debugfs was totally
>>>>>> insecure and it was very trivial to use to crash the kernel.  Which is
>>>>>> why it is a good idea to lock it down and not mount it on "untrusted"
>>>>>> systems.  
>>>>>
>>>>> Based on a discussion on another thread on a public list, there are
>>>>> still remaining issues with debugfs that can cause major problems.  So
>>>>> no one should ever mount it on an untrusted system still.
>>>>>
>>>>> It is getting better, but the issues are tough to resolve, give us
>>>>> another year or so :)
>>>>
>>>> Even if it won't be possible to crash the Kernel or escalate
>>>> privileges, I suspect that several stuff in debugfs should never
>>>> be enabled on production systems, as they may reveal things like
>>>> memory addresses and other stuff that could be used to help someone
>>>> to crack a system.
>>>>
>>>
>>> Unfortunately distros enable DEBUG_FS. I checked a couple of distro configs.
>>>
>>> One popular distro enables:
>>>
>>> CONFIG_BLK_DEBUG_FS=y
>>> CONFIG_KVM_DEBUG_FS=y
>>> CONFIG_DEBUG_FS=y
>>>
>>> Another one enables:
>>>
>>> CONFIG_BLK_DEBUG_FS=y
>>> CONFIG_DEBUG_FS=y
>>>
>>> It looks to me that this message need to be communicated widely so distros can
>>> tighten things up.
>>
>> Luckily debugfs was made "root only by default" a while ago, to help
>> mitigate this problem.  So while it is present on a number of distros,
>> the "attack surface" is greatly reduced.
>>
>> That being said, I bet those distros can drop those config options and
>> be fine.
> 
> Not really. We need those configs to be enabled to be able to troubleshoot
> customer's problems - e.g., asking customer to enable some trace points or
> show some stats from debugfs is pretty common...
> 

Correct. This is the general approach to debug problems in the field and is
necessary to gather information pertaining to the problem.

This is one of the reasons why it is necessary to continue to make debugfs secure
and try to set a higher bar for new debugfs services going forward. I don't think
we can say "don't enable" and it should be "enable at your risk as we try to make
these as secure as possible".

thanks,
-- Shuah

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Sudeep Holla]

On Tue, Oct 02, 2018 at 06:37:43PM -0300, Mauro Carvalho Chehab wrote:

[...]

>
> Even if it won't be possible to crash the Kernel or escalate
> privileges, I suspect that several stuff in debugfs should never
> be enabled on production systems, as they may reveal things like
> memory addresses and other stuff that could be used to help someone
> to crack a system.
>

I completely agree with that. Recently I reviewed patches to support
power management on some ARM platforms which had complete system clock
control in debugfs. It even had access to many system controls that it
can send to remote system control processor which we really don't want
in production systems.

--
Regards,
Sudeep

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

On Wed, Oct 03, 2018 at 11:06:33AM +0100, Sudeep Holla wrote:
> On Tue, Oct 02, 2018 at 06:37:43PM -0300, Mauro Carvalho Chehab wrote:

> > Even if it won't be possible to crash the Kernel or escalate
> > privileges, I suspect that several stuff in debugfs should never
> > be enabled on production systems, as they may reveal things like
> > memory addresses and other stuff that could be used to help someone
> > to crack a system.

> I completely agree with that. Recently I reviewed patches to support
> power management on some ARM platforms which had complete system clock
> control in debugfs. It even had access to many system controls that it
> can send to remote system control processor which we really don't want
> in production systems.

This is why I've always strongly resisted making it possible to write to
the regmap or regulator debugfs files; there is code for writing to the
regmap ones but you need to patch the kernel to enable it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Sudeep Holla]

On Wed, Oct 03, 2018 at 02:13:53PM +0100, Mark Brown wrote:
> On Wed, Oct 03, 2018 at 11:06:33AM +0100, Sudeep Holla wrote:
> > On Tue, Oct 02, 2018 at 06:37:43PM -0300, Mauro Carvalho Chehab wrote:
> 
> > > Even if it won't be possible to crash the Kernel or escalate
> > > privileges, I suspect that several stuff in debugfs should never
> > > be enabled on production systems, as they may reveal things like
> > > memory addresses and other stuff that could be used to help someone
> > > to crack a system.
> 
> > I completely agree with that. Recently I reviewed patches to support
> > power management on some ARM platforms which had complete system clock
> > control in debugfs. It even had access to many system controls that it
> > can send to remote system control processor which we really don't want
> > in production systems.
> 
> This is why I've always strongly resisted making it possible to write to
> the regmap or regulator debugfs files; there is code for writing to the
> regmap ones but you need to patch the kernel to enable it.

Ah, that's better. Next time I see anything around debugfs where
restricting write is a must, I will suggest something on similar lines
so that they need that extra tiny patch to get it enabled. Thanks for
the pointers.

--
Regards,
Sudeep

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Jani Nikula]

On Mon, 01 Oct 2018, Steven Rostedt <rostedt@goodmis.org> wrote:
> At Kernel Recipes, I talked with some people that have mature
> interfaces in the debugfs directory, but they can not access them on
> systems that have debugfs disabled. What would be the process to have
> these systems move out of debugfs? Should they create their own fs and
> be mounted in /sys/kernel, with a dedicated directory if the file system
> is enabled in the kernel (I had tracefs do that).
>
> Is this something we should discuss at Maintainers Summit? What is the
> process for mature debugfs directories? What's the justification to
> have them moved? Is there a better answer for this?

I have a semi-related topic, hopefully not a complete thread
hijack... ;)

I think module parameters should primarily be viewed as debug knobs
rather than ABI. Things should just work instead of requiring the user
to tweak module parameters. Of course, there's the whole spectrum
between ABI and "unsafe" module parameters, and parameters get added for
a plethora of reasons.

However, all module parameters show up in sysfs instead of, say,
debugfs. Many debug options otherwise suitable for debugfs alone are
added as module parameters because of the convenience; with just a few
lines you can add the module parameter, get the sysfs, and have the
value be set before probe. There's nothing that compares, really.

I suppose primarily I'd like to find a convenient way to move module
parameters to debugfs, so the other way round than Steven. Do others
struggle with this? Any ideas, thoughts, pointers?

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Steven Rostedt]

On Tue, 02 Oct 2018 11:40:47 +0300
Jani Nikula <jani.nikula@intel.com> wrote:

> On Mon, 01 Oct 2018, Steven Rostedt <rostedt@goodmis.org> wrote:
> > At Kernel Recipes, I talked with some people that have mature
> > interfaces in the debugfs directory, but they can not access them on
> > systems that have debugfs disabled. What would be the process to have
> > these systems move out of debugfs? Should they create their own fs and
> > be mounted in /sys/kernel, with a dedicated directory if the file system
> > is enabled in the kernel (I had tracefs do that).
> >
> > Is this something we should discuss at Maintainers Summit? What is the
> > process for mature debugfs directories? What's the justification to
> > have them moved? Is there a better answer for this?  
> 
> I have a semi-related topic, hopefully not a complete thread
> hijack... ;)
> 
> I think module parameters should primarily be viewed as debug knobs
> rather than ABI. Things should just work instead of requiring the user
> to tweak module parameters. Of course, there's the whole spectrum
> between ABI and "unsafe" module parameters, and parameters get added for
> a plethora of reasons.
> 
> However, all module parameters show up in sysfs instead of, say,
> debugfs. Many debug options otherwise suitable for debugfs alone are
> added as module parameters because of the convenience; with just a few
> lines you can add the module parameter, get the sysfs, and have the
> value be set before probe. There's nothing that compares, really.

You mean to select some of the parameters to be debugfs knobs?
(obviously we don't want all of them there).

> 
> I suppose primarily I'd like to find a convenient way to move module
> parameters to debugfs, so the other way round than Steven. Do others
> struggle with this? Any ideas, thoughts, pointers?
> 

I haven't had any issues, personally.

-- Steve

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Mauro Carvalho Chehab]

Em Tue, 02 Oct 2018 11:40:47 +0300
Jani Nikula <jani.nikula@intel.com> escreveu:

> On Mon, 01 Oct 2018, Steven Rostedt <rostedt@goodmis.org> wrote:
> > At Kernel Recipes, I talked with some people that have mature
> > interfaces in the debugfs directory, but they can not access them on
> > systems that have debugfs disabled. What would be the process to have
> > these systems move out of debugfs? Should they create their own fs and
> > be mounted in /sys/kernel, with a dedicated directory if the file system
> > is enabled in the kernel (I had tracefs do that).
> >
> > Is this something we should discuss at Maintainers Summit? What is the
> > process for mature debugfs directories? What's the justification to
> > have them moved? Is there a better answer for this?  
> 
> I have a semi-related topic, hopefully not a complete thread
> hijack... ;)
> 
> I think module parameters should primarily be viewed as debug knobs
> rather than ABI. Things should just work instead of requiring the user
> to tweak module parameters. Of course, there's the whole spectrum
> between ABI and "unsafe" module parameters, and parameters get added for
> a plethora of reasons.
> 
> However, all module parameters show up in sysfs instead of, say,
> debugfs. Many debug options otherwise suitable for debugfs alone are
> added as module parameters because of the convenience; with just a few
> lines you can add the module parameter, get the sysfs, and have the
> value be set before probe. There's nothing that compares, really.
> 
> I suppose primarily I'd like to find a convenient way to move module
> parameters to debugfs, so the other way round than Steven. Do others
> struggle with this? Any ideas, thoughts, pointers?

Actually, there are several modprobe parameters on some media
drivers that aren't debug-related. On very cheap hardware, sometimes
the vendor doesn't put any eeprom at the device, or doesn't care enough
to give a PCI or USB ID for his hardware.

So, several media drivers have modprobe parameters in order to help
the module to load the right configuration.

There are more commonly found at PCI devices, but there are some USB
ones that also need those. This is currently found on some really cheap
video grabber boards.

So, moving parameters from sysfs to debugfs is not the right thing
to do, for such usecases. Also, we try to avoid touching the existing
parameters like that, in order to avoid breaking userspace setups.

Regards,
Mauro

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Moving debugfs file systems into sysfs

[Jani Nikula]

On Tue, 02 Oct 2018, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Em Tue, 02 Oct 2018 11:40:47 +0300
> Jani Nikula <jani.nikula@intel.com> escreveu:
>
>> On Mon, 01 Oct 2018, Steven Rostedt <rostedt@goodmis.org> wrote:
>> > At Kernel Recipes, I talked with some people that have mature
>> > interfaces in the debugfs directory, but they can not access them on
>> > systems that have debugfs disabled. What would be the process to have
>> > these systems move out of debugfs? Should they create their own fs and
>> > be mounted in /sys/kernel, with a dedicated directory if the file system
>> > is enabled in the kernel (I had tracefs do that).
>> >
>> > Is this something we should discuss at Maintainers Summit? What is the
>> > process for mature debugfs directories? What's the justification to
>> > have them moved? Is there a better answer for this?  
>> 
>> I have a semi-related topic, hopefully not a complete thread
>> hijack... ;)
>> 
>> I think module parameters should primarily be viewed as debug knobs
>> rather than ABI. Things should just work instead of requiring the user
>> to tweak module parameters. Of course, there's the whole spectrum
>> between ABI and "unsafe" module parameters, and parameters get added for
>> a plethora of reasons.
>> 
>> However, all module parameters show up in sysfs instead of, say,
>> debugfs. Many debug options otherwise suitable for debugfs alone are
>> added as module parameters because of the convenience; with just a few
>> lines you can add the module parameter, get the sysfs, and have the
>> value be set before probe. There's nothing that compares, really.
>> 
>> I suppose primarily I'd like to find a convenient way to move module
>> parameters to debugfs, so the other way round than Steven. Do others
>> struggle with this? Any ideas, thoughts, pointers?
>
> Actually, there are several modprobe parameters on some media
> drivers that aren't debug-related. On very cheap hardware, sometimes
> the vendor doesn't put any eeprom at the device, or doesn't care enough
> to give a PCI or USB ID for his hardware.
>
> So, several media drivers have modprobe parameters in order to help
> the module to load the right configuration.
>
> There are more commonly found at PCI devices, but there are some USB
> ones that also need those. This is currently found on some really cheap
> video grabber boards.
>
> So, moving parameters from sysfs to debugfs is not the right thing
> to do, for such usecases. Also, we try to avoid touching the existing
> parameters like that, in order to avoid breaking userspace setups.

As I tried to say, there certainly are plenty of legitimate cases like
this. It's just that there are also plenty of cases where debugfs would
clearly be the right place, without a module parameter at all, but you
can't make the debug parameters take effect at probe time. Because you
obviously need to have the driver register the debugfs files first.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center