linux-kernel - Re: [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem

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]

Message-ID: <ea8db10a-503d-b1b6-2674-8533bb804715@arm.com>
Date:   Thu, 7 Nov 2019 08:04:37 +0530
From:   Anshuman Khandual <anshuman.khandual@....com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [PATCH] efi: Return EFI_RESERVED_TYPE in efi_mem_type() for
 absent addresses



On 11/06/2019 10:31 PM, Ard Biesheuvel wrote:
> On Tue, 5 Nov 2019 at 21:39, Anshuman Khandual
> <anshuman.khandual@....com> wrote:
>>
>> The function efi_mem_type() is expected (per documentation above) to return
>> EFI_RESERVED_TYPE when a given physical address is not present in the EFI
>> memory map. Even though EFI_RESERVED_TYPE is not getting checked explicitly
>> anywhere in the callers, it is always better to return expected values.
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>
>> Cc: linux-efi@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> 
> This reverts commit f99afd08a45fbbd9ce35a7624ffd1d850a1906c0.
> 
> Could you explain why it is better to fix the code than fix the comment?

>From the above commit message, its not clear how returning EFI_RESERVED_TYPE
would have meant that a memory descriptor really exists.

Just wondering if firmware itself can send across memory descriptors with
EFI_RESERVED_TYPE attribute or it is only a software specific attribute ?
Currently it is being used while merging two adjacent regions with similar
type and attributes. Searching for physical addresses within those merged
memory descriptors will return EFI_RESERVED_TYPE but that is different than
the entry not being present at all. So I think the previous commit which
introduced -EINVAL/-ENOTSUPP in place for EFI_RESERVED_TYPE did the right
thing.

We should fix the comment instead, will send a patch.

> 
>> ---
>>  drivers/firmware/efi/efi.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
>> index 69f00f7453a3..bdda90a4601e 100644
>> --- a/drivers/firmware/efi/efi.c
>> +++ b/drivers/firmware/efi/efi.c
>> @@ -914,7 +914,7 @@ int efi_mem_type(unsigned long phys_addr)
>>                                   (md->num_pages << EFI_PAGE_SHIFT))))
>>                         return md->type;
>>         }
>> -       return -EINVAL;
>> +       return EFI_RESERVED_TYPE;
>>  }
>>  #endif
>>
>> --
>> 2.20.1
>>