All of lore.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usamaarif642@gmail.com>
To: Dave Young <dyoung@redhat.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-efi@vger.kernel.org, devel@edk2.groups.io,
	kexec@lists.infradead.org, hannes@cmpxchg.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, leitao@debian.org,
	gourry@gourry.net, kernel-team@meta.com
Subject: Re: [RFC 1/2] efi/memattr: Use desc_size instead of total size to check for corruption
Date: Wed, 22 Jan 2025 11:50:24 +0000	[thread overview]
Message-ID: <1a4223a2-77ae-4f15-a40b-dc33de9e6c2d@gmail.com> (raw)
In-Reply-To: <CALu+AoS5_w2CV5w+b1WrFRFH7nfwmkLZUh=AXn=D=7rAhDNVAQ@mail.gmail.com>



On 22/01/2025 05:36, Dave Young wrote:
> Hi,
> On Mon, 20 Jan 2025 at 19:48, Usama Arif <usamaarif642@gmail.com> wrote:
>>
>>
>>
>> On 20/01/2025 11:29, Ard Biesheuvel wrote:
>>> On Mon, 20 Jan 2025 at 11:50, Usama Arif <usamaarif642@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On 20/01/2025 10:32, Ard Biesheuvel wrote:
>>>>> On Mon, 20 Jan 2025 at 11:27, Usama Arif <usamaarif642@gmail.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@debian.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


  reply	other threads:[~2025-01-22 11:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08 21:53 [RFC 0/2] efi/memattr: Fix memory corruption and warning issues Usama Arif
2025-01-08 21:53 ` [RFC 1/2] efi/memattr: Use desc_size instead of total size to check for corruption Usama Arif
2025-01-09 15:45   ` Ard Biesheuvel
2025-01-09 16:36     ` Usama Arif
2025-01-10  7:21       ` Ard Biesheuvel
2025-01-10 10:53         ` Usama Arif
2025-01-10 17:25           ` Ard Biesheuvel
2025-01-13  2:33           ` Dave Young
2025-01-13 11:27             ` Usama Arif
2025-01-13 12:00               ` Usama Arif
2025-01-20 10:27                 ` Usama Arif
2025-01-20 10:32                   ` Ard Biesheuvel
2025-01-20 10:50                     ` Usama Arif
2025-01-20 11:29                       ` Ard Biesheuvel
2025-01-20 11:48                         ` Usama Arif
2025-01-22  5:36                           ` Dave Young
2025-01-22 11:50                             ` Usama Arif [this message]
2025-01-08 21:53 ` [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware Usama Arif
2025-01-09 16:15   ` Ard Biesheuvel
2025-01-09 16:32     ` Usama Arif
2025-01-09 16:47       ` Gregory Price
2025-01-10  7:32       ` Ard Biesheuvel
2025-01-10 11:36         ` Breno Leitao
2025-01-10 17:33           ` Ard Biesheuvel
2025-01-10 14:31         ` Usama Arif
2025-01-10 15:50           ` Usama Arif
2025-01-10  2:50   ` Dave Young
2025-01-10 11:12     ` Usama Arif
2025-01-10 11:18       ` Dave Young
2025-01-10 11:20         ` Dave Young
2025-01-10 11:42           ` Usama Arif
2025-01-10  6:56   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a4223a2-77ae-4f15-a40b-dc33de9e6c2d@gmail.com \
    --to=usamaarif642@gmail.com \
    --cc=ardb@kernel.org \
    --cc=devel@edk2.groups.io \
    --cc=dyoung@redhat.com \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@meta.com \
    --cc=kexec@lists.infradead.org \
    --cc=leitao@debian.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.