Re: [PATCH] firmware: make sure paths remain relative

[Kees Cook]

On Mon, Dec 17, 2012 at 6:15 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
> On Tue, Dec 18, 2012 at 9:37 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> On Mon, Dec 17, 2012 at 5:30 PM, Ming Lei <ming.lei@xxxxxxxxxxxxx> wrote:
>>> On Sat, Dec 15, 2012 at 6:51 AM, Kees Cook <keescook@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/