On Tue, 2017-04-18 at 09:06 +0300, Andy Shevchenko wrote: > > On Mon, Apr 10, 2017 at 4:16 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > > > > Andy Shevchenko <andy.shevchenko@xxxxxxxxx> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
