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: <1a4223a2-77ae-4f15-a40b-dc33de9e6c2d@gmail.com>
Date: Wed, 22 Jan 2025 11:50:24 +0000
From: Usama Arif <usamaarif642@...il.com>
To: Dave Young <dyoung@...hat.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, linux-efi@...r.kernel.org,
 devel@...2.groups.io, kexec@...ts.infradead.org, hannes@...xchg.org,
 x86@...nel.org, linux-kernel@...r.kernel.org, leitao@...ian.org,
 gourry@...rry.net, kernel-team@...a.com
Subject: Re: [RFC 1/2] efi/memattr: Use desc_size instead of total size to
 check for corruption



On 22/01/2025 05:36, Dave Young wrote:
> Hi,
> On Mon, 20 Jan 2025 at 19:48, Usama Arif <usamaarif642@...il.com> wrote:
>>
>>
>>
>> On 20/01/2025 11:29, Ard Biesheuvel wrote:
>>> On Mon, 20 Jan 2025 at 11:50, Usama Arif <usamaarif642@...il.com> wrote:
>>>>
>>>>
>>>>
>>>> On 20/01/2025 10:32, Ard Biesheuvel wrote:
>>>>> On Mon, 20 Jan 2025 at 11:27, Usama Arif <usamaarif642@...il.com> wrote:
>>>>>>
>>>>>>
>>>>> ...
>>>>>> Hi Ard,
>>>>>>
>>>>>> Just wanted to check how should we proceed forward? Should we try and fix the warning
>>>>>> and corruption during kexec as done in this series or not initialize memory attributes
>>>>>> table at all in kexec boot? I would prefer fixing the issues as in this series.
>>>>>>
>>>>>
>>>>> I would prefer kexec boot on x86 to disregard the memory attributes
>>>>> table entirely.
>>>>
>>>> Would you like Dave to send something like
>>>> https://lore.kernel.org/all/CALu+AoS8tb=HgaybDw5OG4A1QbOXHvuidpu0ynmz-nE1nBqzTA@mail.gmail.com/
>>>> on the mailing list (wrapped in ifdef CONFIG_X86_64)
>>>>
>>>
>>> I prefer this approach. and no need for the ifdef, this is x86
>>> specific code, and the memory attributes table is already ignored
>>> entirely on 32-bit x86 iirc
>>
>> ah yes, I ignored the file name when reviewing it and just focused on the function :)
>>
>> Will wait for Dave to send it.
> 
> Ok,  I will add reported-by from you and suggested-by from Ard.  But I
> can not test the efi mem attr, I'd prefer to have your test results
> first.  Could you confirm that?
> 

Please also add Reported-by: Breno Leitao <leitao@...ian.org>
who originally discovered and reported the issue.

I have tested it and it works, efi_memattr_init will just return 0 as
efi_mem_attr_table = EFI_INVALID_TABLE_ADDR, so it won't be
initialized. Feel free to add Tested-by tag from me.

Thanks,
Usama

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ