Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1625047 > unrolled thread
| Started by | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| First post | 2017-04-18 08:10 +0200 |
| Last post | 2017-04-18 19:40 +0200 |
| Articles | 7 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
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
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2017-04-18 08:10 +0200 |
| Subject | Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down |
| Message-ID | <txuuS-2Go-11@gated-at.bofh.it> |
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). If one still needs debugfs in secure mode, it sounds to me as architectural bug in code in question. > > Note that it's still going to be a driver burden to some extent anyway. The > driver has to tell the core what needs to be restricted. > > Further, I guess configfs needs attention also. -- With Best Regards, Andy Shevchenko
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2017-04-18 16:40 +0200 |
| Message-ID | <txCsp-7gY-9@gated-at.bofh.it> |
| In reply to | #1625047 |
[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.
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2017-04-18 17:00 +0200 |
| Subject | Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down |
| Message-ID | <txCLL-7nt-25@gated-at.bofh.it> |
| In reply to | #1625370 |
Ben Hutchings <ben@decadent.org.uk> wrote: > - tracing (now tracefs, but it's expected to appear under debugfs) Shouldn't this now appear under /sys/kernel/tracing/ ? David
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2017-04-18 17:30 +0200 |
| Message-ID | <txDeN-7Mn-15@gated-at.bofh.it> |
| In reply to | #1625378 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2017-04-18 at 15:55 +0100, David Howells wrote: > Ben Hutchings <ben@decadent.org.uk> wrote: > > > - tracing (now tracefs, but it's expected to appear under debugfs) > > Shouldn't this now appear under /sys/kernel/tracing/ ? True, but old tracing scripts didn't go away. Ben. -- Ben Hutchings The world is coming to an end. Please log off.
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2017-04-18 17:40 +0200 |
| Subject | Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down |
| Message-ID | <txDot-7Pj-3@gated-at.bofh.it> |
| In reply to | #1625400 |
Ben Hutchings <ben@decadent.org.uk> wrote: > > Shouldn't this now appear under /sys/kernel/tracing/ ? > > True, but old tracing scripts didn't go away. Conversion to a symlink would fix that. David
[toc] | [prev] | [next] | [standalone]
| From | David Howells <dhowells@redhat.com> |
|---|---|
| Date | 2017-04-18 17:40 +0200 |
| Subject | Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down |
| Message-ID | <txDou-7Pj-7@gated-at.bofh.it> |
| In reply to | #1625370 |
Ben Hutchings <ben@decadent.org.uk> wrote: > 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. Any suggestion on how to mark this distinction? I'd prefer not to modify every read/write op associated with a debugfs file. Modify DEFINE_DEBUGFS_ATTRIBUTE() maybe? And provide lockable variants of debugfs_create_u8() and co.? David
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2017-04-18 19:40 +0200 |
| Message-ID | <txFgC-un-33@gated-at.bofh.it> |
| In reply to | #1625405 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, 2017-04-18 at 16:30 +0100, David Howells wrote: > Ben Hutchings <ben@decadent.org.uk> wrote: > > > 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. > > Any suggestion on how to mark this distinction? I don't know. > I'd prefer not to modify every read/write op associated with a > debugfs file. I think debugfs should be assumed unsafe by default. So only the believed-safe parts would need to be changed. > Modify > DEFINE_DEBUGFS_ATTRIBUTE() maybe? And provide lockable variants of > debugfs_create_u8() and co.? That could help. Ben. -- Ben Hutchings The world is coming to an end. Please log off.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web