From: fuqiang wang <fuqiang.wang@easystack.cn>
To: Yuntao Wang <ytcoode@gmail.com>
Cc: bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, vgoyal@redhat.com
Subject: Re: [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range()
Date: Tue, 19 Dec 2023 16:55:16 +0800 [thread overview]
Message-ID: <3765549d-892e-4102-9b56-9add1d0a8089@easystack.cn> (raw)
In-Reply-To: <20231219052955.40414-1-ytcoode@gmail.com>
在 2023/12/19 13:29, Yuntao Wang 写道:
> On Tue, 19 Dec 2023 11:50:32 +0800, fuqiang wang <fuqiang.wang@easystack.cn> wrote:
>> 在 2023/12/19 10:47, Yuntao Wang 写道:
>>
>>> Hi fuqiang,
>>>
>>> Yesterday, I posted two patches that happen to address the bugs you an Baoquan
>>> are currently discussing here, I wasn't aware that you both were also working
>>> on fixing these issues.
>>>
>>> Baoquan suggested I talk to you about it.
>>>
>>> If you're interested, you can take a look at my patches and review them to see
>>> if there are any issues. If everything is fine, and if you're willing, you can
>>> also add a 'Reviewed-by' tag there.
>>>
>>> The following link is for the two patches I posted yesterday:
>>>
>>> https://lore.kernel.org/lkml/20231218081915.24120-3-ytcoode@gmail.com/t/#u
>>>
>>> Sincerely,
>>> Yuntao
>> Hi Yuntao,
>>
>> I'm glad you've also noticed this issue. But I'm sorry, I want to solve this
>> problem myself because this is my first time posting a patch in the community,
>> and I cherish this opportunity very much.
> I can truly understand your feelings because I still remember how thrilled I
> was when my first patch got merged. So keep it up!
Hi Yuntao,
Thanks for your understanding and encourage. :)
>> I have carefully reviewed your patch. There is some changes where my views differ
>> from yours:
>> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
>> index c92d88680dbf..3be46f4b441e 100644
>> --- a/arch/x86/kernel/crash.c
>> +++ b/arch/x86/kernel/crash.c
>> @@ -282,10 +282,6 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
>> struct crash_memmap_data cmd;
>> struct crash_mem *cmem;
>>
>> - cmem = vzalloc(struct_size(cmem, ranges, 1));
>> - if (!cmem)
>> - return -ENOMEM;
>> -
>> memset(&cmd, 0, sizeof(struct crash_memmap_data));
>> cmd.params = params;
>>
>> @@ -321,6 +317,11 @@ int crash_setup_memmap_entries(struct kimage *image, struct boot_params *params)
>> }
>>
>> /* Exclude some ranges from crashk_res and add rest to memmap */
>> + cmem = vzalloc(struct_size(cmem, ranges, 1));
>> + if (!cmem)
>> + return -ENOMEM;
>> + cmem->max_nr_ranges = 1;
>> +
>> ret = memmap_exclude_ranges(image, cmem, crashk_res.start, crashk_res.end);
>> if (ret)
>> goto out;
>>
>> 1. I don't feel very good that you have moved vzalloc() to in front of
>> memmap_exclude_ranges. Because if memory allocation fails, there is no need to
>> do anything else afterwards.
> I moved it here because only memmap_exclude_ranges() and the code below it use cmem.
>
> I think it is a good practice to put related code together, which also improves
> code readability.
Thank you very much for your patient comment. This change does indeed improve
readability. But as a combination of these two, how do you feel about moving
crash_setup_memmap_entries() behind vzalloc().
>> 2. The cmem->max_nr_ranges should be set to 2. Because in
>> memmap_exclude_ranges, a cmem->ranges[] will be filled in and if a split occurs
>> later, another one will be added.
> With the current code, image->elf_load_addr should be equal to crashk_res.start,
> so split will not occur in crash_exclude_mem_range(). Therefore, setting
> cmem->max_nr_ranges to 1 is safe.
The image->elf_load_addr is determined by arch_kexec_locate_mem_hole(), this
function can ensure that the value is within the range of [crashk_res.start,
crashk_res.end), but it seems that it cannot guarantee that its value will
always be equal to crashk_res.start. Perhaps I have some omissions, please
point them out.
Thanks
fuqiang
>> Thanks
>> fuqiang
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2023-12-19 8:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 2:56 [PATCH] kexec: avoid out of bounds in crash_exclude_mem_range() fuqiang wang
2023-11-30 7:44 ` Baoquan He
2023-11-30 13:20 ` fuqiang wang
2023-12-13 4:44 ` Baoquan He
2023-12-13 13:10 ` fuqiang wang
2023-12-14 9:17 ` Baoquan He
2023-12-14 10:29 ` Baoquan He
2023-12-18 8:31 ` fuqiang wang
2023-12-19 2:42 ` Yuntao Wang
2023-12-19 2:47 ` Yuntao Wang
2023-12-19 3:50 ` fuqiang wang
2023-12-19 5:29 ` Yuntao Wang
2023-12-19 8:55 ` fuqiang wang [this message]
2023-12-19 10:39 ` Yuntao Wang
2023-12-19 12:54 ` fuqiang wang
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=3765549d-892e-4102-9b56-9add1d0a8089@easystack.cn \
--to=fuqiang.wang@easystack.cn \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=ytcoode@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox