linux-kernel - Re: [PATCH] firmware: Be a bit more verbose about direct firmware loading failure

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Sep 2013 10:56:39 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Neil Horman <nhorman@...driver.com>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH] firmware: Be a bit more verbose about direct firmware
 loading failure

On Thu, 12 Sep 2013, Neil Horman wrote:
> On Thu, Sep 12, 2013 at 03:46:30PM -0300, Henrique de Moraes Holschuh wrote:
> > On Thu, 12 Sep 2013, Neil Horman wrote:
> > > Both of these execptions should be rare, and are something the administrator
> > > will want to know about, so as not to confuse the real error with the mystery
> > > -ENOENT you would get if you fell back to the user mode helepr and it wansn't
> > > configured on in the running kernel.
> > 
> > Except, of course, for Intel processor microcode updates, which are going to
> > cause ENOENT on a large number of systems.
> > 
> > This will generate a large number of questions by users on the distro MLs.
> > 
> > However, IMHO this is *not* a reason to refuse this patch series.  If
> > anything, at least for Debian I will use it as an opportunity to educate
> > people about the existence of microcode update packages in "non-free".
> > 
> I agree. If people are running with downlevel microcode, they shold know about
> it.  You can't expect request_firmware to fail silently.  If people complain, I
> think the right solution would be to add a test to the microcode_request_fw
> function to check for the existence of the file before requesting it.

Make it a firmware loader API for "optional" firmware (i.e. which doesn't
complain on ENOENT), leaving for the caller the detail of whether a
firmware-not-there failure should be logged or not.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/