Inaccurate deblobbing breaks rtl8192ce

[Lobachevskii Vitalii]

Hello,

About “surprising” the driver: -EINVAL means that firmware load
machinery is absent, while the rtl8192ce driver (as well as many others)
explicitly depend on it (select FW_LOADER), so that’s not possible in
any correct kernel configuration.

Anyway, driver maintainers answered. Well, I expected such answer. And
I’m afraid they’re right in that the device runs some firmware anyway;
that may be the firmware included on production or last loaded (or maybe
EFI loads it on boot? well, don’t know).

Actually, for a long time I wanted to ask: what’s the real point to
remove firmware from the kernel? That’s not security: complex devices
can’t work without a firmware, so either they don’t work at all or have
some sort of built-in firmware, that may pose all the same security
risks; that’s not the freedom, as unchangeable program on disk isn’t any
worse than unchangeable program in ROM; so what?

By the way, I tried the approach with callback calling, it seems it
doesn’t break anything but neither lets this driver (unaltered) to work.
And the modified driver works somewhat, often crashing the program that
tries to perform scan (tested wpa_supplicant and iw, both crash with
SEGFAULT). It seems that depends on the device state on boot/resume,
which can be different for some reason.

-- 
Lobachevskii Vitalii  https://github.com/numberZero

On 18.08.2016 22:14, Alexandre Oliva wrote:
> Hi,
>
> Thanks for your report!
>
> On Aug 13, 2016, number Zero <silverunicorn2011 at yandex.ru> wrote:
>
>> However, after I made it to ignore the EINVAL error from the
>> reject_firmware_nowait function (in
>> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c), it works fine.
> Interesting.  Can you check that this remains true even after a full
> power cycle, as in, that it's not a blob loaded by a previous blobbed
> kernel that remains it to work in your setting?  (if you never had the
> blob around, or never used a blobbed kernel, just say so, and I'll be
> happy enough about the conclusion ;-)
>
>> Really, are there any reasons for reject_firmware_nowait to return
>> -EINVAL?
> Yes.  It the error code to indicate to the caller that the firmware
> loading functionality is not avaialble.  It indicates the callback
> supplied by the caller will not be called, so the caller itself should
> take care of e.g. returning any temporary memory the callback would have
> released.
>
> If the driver works even if request_firmware_nowait returns such an
> error, then it ought to tolerate this return code.
>
>> So shouldn’t the reject_firmware_nowait function behave as if the
>> requested firmware merely absent?
> Given the multiple cases in which drivers were "surprised" by this
> return code, I guess we could try to rework reject_firmware_nowait so as
> to actually call the callback, signalling the unsuccessful completion of
> the request.  Would you like to give that a try?
>
> Or perhaps you'd prefer to report the bug to the rtl8192ce maintainers,
> so that they could fix their driver so as to work (as it should) even
> when the firmware loading configuration option is disabled?
>
> Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20160826/b3311c02/attachment.html>
-------------- next part --------------
An embedded message was scrubbed...
From: Jes Sorensen <Jes.Sorensen at redhat.com>
Subject: Re: rtl8192ce
Date: Thu, 25 Aug 2016 11:13:45 -0400
Size: 5010
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20160826/b3311c02/attachment.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: Larry Finger <Larry.Finger at lwfinger.net>
Subject: Re: rtl8192ce
Date: Thu, 25 Aug 2016 09:59:30 -0500
Size: 6030
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20160826/b3311c02/attachment-0001.mht>
-------------- next part --------------
An embedded message was scrubbed...
From: Jes Sorensen <Jes.Sorensen at redhat.com>
Subject: Re: rtl8192ce
Date: Thu, 25 Aug 2016 09:17:54 -0400
Size: 3802
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20160826/b3311c02/attachment-0002.mht>