On Mon, Dec 17, 2012 at 6:15 PM, Ming Lei <ming....@canonical.com> wrote: > On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook <keesc...@chromium.org> wrote: >> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei <ming....@canonical.com> wrote: >>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook <keesc...@chromium.org> wrote: >>>> Some devices have configurable firmware locations. If these configuration >>>> mechanisms are exposed to unprivileged userspace, it may be possible to >>> >>> I an wondering how the unprivileged userspace can write the firmware sysfs >>> to trigger loading firmware? >> >> If a daemon were to, for example, make firmware selectable by the user >> (which under certain situations is possible in Chrome OS), it seems >> wasteful require these userspace tools/interfaces to each perform >> filtering, so I figured it would be trivial to put in here instead to >> avoid possible future vulnerabilities. > > OK, I understand your concern, and looks reasonable wrt. the specific > problem, and IMO, it is better to provide failure log so that the affected > device driver can be fixed easily.
Do you mean a printk should be emitted on this error path? I can add that if so. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
