summaryrefslogtreecommitdiff
path: root/drivers/base/devcoredump.c
AgeCommit message (Collapse)AuthorFilesLines
2014-11-27devcoredump: provide a one-way disable functionJohannes Berg1-8/+48
Since device/firmware coredumps can contain private data, it can be desirable to turn them off unconditionally to be certain that no such data will be collected by the system. To achieve this, provide a "disabled" sysfs class attribute that can only be changed from 0 to 1 and not back. Upon disabling, discard existing coredumps and stop storing new ones. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-24device coredump: add new device coredump classJohannes Berg1-0/+265
Many devices run firmware and/or complex hardware, and most of that can have bugs. When it misbehaves, however, it is often much harder to debug than software running on the host. Introduce a "device coredump" mechanism to allow dumping internal device/firmware state through a generalized mechanism. As devices are different and information needed can vary accordingly, this doesn't prescribe a file format - it just provides mechanism to get data to be able to capture it in a generalized way (e.g. in distributions.) The dumped data will be readable in sysfs in the virtual device's data file under /sys/class/devcoredump/devcd*/. Writing to it will free the data and remove the device, as does a 5-minute timeout. Note that generalized capturing of such data may result in privacy issues, so users generally need to be involved. In order to allow certain users/system integrators/... to disable the feature at all, introduce a Kconfig option to override the drivers that would like to have the feature. For now, this provides two ways of dumping data: 1) with a vmalloc'ed area, that is then given to the subsystem and freed after retrieval or timeout 2) with a generalized reader/free function method We could/should add more options, e.g. a list of pages, since the vmalloc area is very limited on some architectures. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>