linux-kernel - Re: [PATCH] udev: fail firmware loading immediately if no search path is defined

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAPXgP11LnVqTxsKUoLTLwtP-oxcekkNxmPG2X-R+2U9S4-dAgQ@mail.gmail.com>
Date:	Sat, 10 Aug 2013 23:28:18 +0200
From:	Kay Sievers <kay@...y.org>
To:	Tom Gundersen <teg@...m.no>
Cc:	Maarten Lankhorst <m.b.lankhorst@...il.com>,
	Linux Wireless List <linux-wireless@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Intel Linux Wireless <ilw@...ux.intel.com>,
	Johannes Berg <johannes@...solutions.net>,
	linux-hotplug@...r.kernel.org,
	Bryan Kadzban <bryan@...zban.is-a-geek.net>,
	systemd Mailing List <systemd-devel@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] udev: fail firmware loading immediately if no search path
 is defined

On Sat, Aug 10, 2013 at 11:00 PM, Tom Gundersen <teg@...m.no> wrote:
> It would be simple enough to add an udev rule to just print 'ignoring
> firmware event' to the logs.

This and I guess:
  SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"
would also just cancel the request at the same time without any other
code needed.

The udev firmware support just a configure option, just like the
kernel has them. So distributions should enable it in udev and the
kernel if they need it.

We simply cannot coordinate the defaults of systemd and the kernel
because the rules of the kernel are different. The kernel does "keep
defaults like stuff has been in the past" and udev does "make default
what makes the most sense on current systems".

> We should really ignore the event though, and
> not cancel it. Not sure if this is something we want upstream (after all,
> there are plenty of situations where we don't warn if the recommendations in
> the README file are not followed), or if distros and whoever wants it should
> ship that themselves. I'll leave that for Kay to decide.

The proper fix is that userspace firmware should be disabled in the
kernel for new systems, and kept enabled only for old systems. Old
systems need to enable a new udev version to support firmware loading.

There are currently broken in-kernel mis-users of the firmware
interface that use the firmware interface but disable uevents, they
still pull-in the user interface of the firmware loader. If nobody
wants to fix them, the code for the common users of the firmware
loader should at least get rid of the userspace fallback to call out
to userspace. At that point the udev configure option would not matter
any more.

> Lastly, note that the plan is to drop all the firmware code from udev in the
> not too distant future, so it doesn't really maker much sense to add new
> functionality to that at this point.

Right, I think all is fine. It's something that people can control
with the kernel and udev configuration options. It's just that the
defaults of the kernel and udev don't match at the moment, because
they have different policies of setting default values.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/