linux-kernel - Re: [PATCH] firmware: dmi: handle missing DMI data gracefully

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

Date:   Tue, 17 Oct 2017 09:18:29 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Jean Delvare <jdelvare@...e.de>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: dmi: handle missing DMI data gracefully

On 17 October 2017 at 08:27, Jean Delvare <jdelvare@...e.de> wrote:
> Hi Ard,
>
> On Thu, 12 Oct 2017 20:59:37 +0100, Ard Biesheuvel wrote:
>> Currently, when booting a kernel with DMI support on a platform that has
>> no DMI tables, the following output is emitted into the kernel log:
>>
>>   [    0.128818] DMI not present or invalid.
>>   ...
>>   [    1.306659] dmi: Firmware registration failed.
>>   ...
>>   [    2.908681] dmi-sysfs: dmi entry is absent.
>>
>> The first one is a pr_info(), but the subsequent ones are pr_err()s that
>> complain about a condition that is not really an error to begin with.
>>
>> So let's clean this up, and give up silently if dma_available is not set.
>
> On the principle I agree, but you'll have to come up with an
> implementation that links successfully:
>
> ERROR: "dmi_available" [drivers/firmware/dmi-sysfs.ko] undefined!
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
> make[1]: *** [__modpost] Error 1
> Makefile:1216: recipe for target 'modules' failed
> make: *** [modules] Error 2
>

Oops. Thanks for spotting that.

> The reason is that dmi_available is not exported. The obvious solution
> is to export it. Or maybe just turn the error message into a debug
> message and assume the only reason it may reasonably happen is because
> dmi isn't available in the first place. If dmi_kobj is missing for any
> other reason then there's a much more important problem to solve anyway.
>

Indeed. dmi_kobj is the first thing that gets created in dmi_init(),
and if that fails you will get a pr_err() anyway.

I will respin.

Thanks,
Ard.


>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> ---
>>  drivers/firmware/dmi-sysfs.c | 3 +++
>>  drivers/firmware/dmi_scan.c  | 6 ++----
>>  2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
>> index d5de6ee8466d..3a264cbbb5a6 100644
>> --- a/drivers/firmware/dmi-sysfs.c
>> +++ b/drivers/firmware/dmi-sysfs.c
>> @@ -651,6 +651,9 @@ static int __init dmi_sysfs_init(void)
>>       int error;
>>       int val;
>>
>> +     if (!dmi_available)
>> +             return 0;
>> +
>>       if (!dmi_kobj) {
>>               pr_err("dmi-sysfs: dmi entry is absent.\n");
>>               error = -ENODATA;
>> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
>> index 783041964439..17a7425063c2 100644
>> --- a/drivers/firmware/dmi_scan.c
>> +++ b/drivers/firmware/dmi_scan.c
>> @@ -715,10 +715,8 @@ static int __init dmi_init(void)
>>       u8 *dmi_table;
>>       int ret = -ENOMEM;
>>
>> -     if (!dmi_available) {
>> -             ret = -ENODATA;
>> -             goto err;
>> -     }
>> +     if (!dmi_available)
>> +             return 0;
>>
>>       /*
>>        * Set up dmi directory at /sys/firmware/dmi. This entry should stay
>
> --
> Jean Delvare
> SUSE L3 Support