linux-kernel - Re: [PATCH] x86/e820: update code comment about e820_table

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

Message-ID: <CALu+AoSKCtU4iGRM8LH6qYbgKvZ79=zfC8kXXb_GJqp=mpEdFg@mail.gmail.com>
Date: Fri, 10 Jan 2025 14:29:36 +0800
From: Dave Young <dyoung@...hat.com>
To: Chen Yu <yu.c.chen@...el.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH] x86/e820: update code comment about e820_table_kexec

> BTW,  the conversation below drived me to read the e820 code:
> https://lore.kernel.org/all/CAMj1kXG1hbiafKRyC5qM1Vj5X7x-dmLndqqo2AYnHMRxDz-80w@mail.gmail.com/T/#u
>
> It could be better to clean up the e820 tables, anyway the comment fix
> in this patch itself is good for now.
>
> Basically e820_table_firmware is used by kexec-tools kexec_load
> implementation,  e820_table_kexec is used by kexec_file_load code to
> pass to the 2nd kernel in boot params.
>
> The e820_table_firmware is said to not be modified by the kernel in
> the code comment, but this is not true, at least the sev code updates
> the table.    The hibernate code generates crc32 checksum and verifies
> it, but since AFAIK e820 table update only happens in boot phase, it
> will be stable on runtime.  So we can just use e820_table_firmware for
> kexec use and drop the e820_table_kexec. With the change the
> kexec_file_load and kexec_load see the same memory ranges.
>
> Otherwise I thought we can use just one e820 table, dropping
> e820_table_firmware and e820_table_kexec, but then there will be
> fragments and memory waste  due to the setup_data ranges are reserved
> and updated in e820_table, so the e820_table_firmware being still be
> used for kexec makes sense.
>
> Anyway I need to think more about it,  please let me know if you have
> any concerns.

Reread the old commit 12df216c61c89e31e27e74146115a9728880ca6f
    x86/boot/e820: Introduce the bootloader provided e820_table_firmware[] table

It seems the e820_table_firmware was changed to be exported in sysfs
instead of e820_table_kexec,   but I suspect this is wrong.
kexec-tools (kexec_load) use the exported sysfs memmap info,  but
e820_table_firmware was created by above commit to be used by
hibernation and the table should not be changed,  the fact is there
are changes happen from time to time.

Question is does hibernation use the sysfs entries from its userspace
tools?  If yes, then we should have both kexec table and firmware
table exported because they are for different purposes and one may
change, another not.

If hibernation only uses the table within the kernel then it makes no
sense to export it to sysfs, we should only export the kexec table for
kexec-tools use.  In this way  both kexec_load (userspace) and
kexec_file_load (kernel load) can use same e820 table, it will reduce
the bugs and be easier to maintain.

Thanks
Dave