Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1625370
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down |
| Date | 2017-04-18 16:40 +0200 |
| Message-ID | <txCsp-7gY-9@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <ttzjr-5Oz-3@gated-at.bofh.it> <ttBEC-7cJ-17@gated-at.bofh.it> <tuj2V-24s-1@gated-at.bofh.it> <tuHoC-18n-37@gated-at.bofh.it> <txuuS-2Go-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Tue, 2017-04-18 at 09:06 +0300, Andy Shevchenko wrote: > > On Mon, Apr 10, 2017 at 4:16 PM, David Howells <dhowells@redhat.com> wrote: > > > > Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > > > > > > It looks a bit fragile when responsility of whatever reasons kernel > > > > > can't serve become a driver burden. > > > > > Can we fix this in debugfs framework instead? > > > > > > > > Fix it with debugfs how? We can't offload the decision to userspace. > > > > > > I mean to do at least similar like you have done for module > > > parameters. So, instead of putting above code to each attribute in > > > question make a special (marked) attribute instead and debugfs > > > framework will know how to deal with that. > > > > Hmmm... It's tricky in that debugfs doesn't have any of its own structures, > > but is entirely built on standard VFS ones, so finding somewhere to store the > > information is going to be awkward. > > I see. > > > One obvious solution is to entirely lock > > down debugfs in secure boot more, but that might be a bit drastic. > > But this sounds sane! debugFS for debugging, not for production. If > someone is using secure kernel it means pure production use (otherwise > one may do temporary hacks in kernel). [...] Production systems need instrumentation to understand performance issues and any bugs that for whatever reason didn't show up in earlier testing. A number of interfaces for that have been added under debugfs: - tracing (now tracefs, but it's expected to appear under debugfs) - dynamic_debug - various ad-hoc statistics So it's generally not going to be OK to turn off debugfs. There will probably need to be a distinction between believed-safe and unsafe directories/files. Ben. -- Ben Hutchings The world is coming to an end. Please log off.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-18 08:10 +0200
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down Ben Hutchings <ben@decadent.org.uk> - 2017-04-18 16:40 +0200
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-18 17:00 +0200
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down Ben Hutchings <ben@decadent.org.uk> - 2017-04-18 17:30 +0200
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-18 17:40 +0200
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down David Howells <dhowells@redhat.com> - 2017-04-18 17:40 +0200
Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down Ben Hutchings <ben@decadent.org.uk> - 2017-04-18 19:40 +0200
csiph-web