linux-kernel - Re: [PATCH v2 1/3] x86/boot: Introduce the kernel

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: <dda802de-2efe-3d22-7816-6da36bf9ebf8@zytor.com>
Date:   Tue, 1 Oct 2019 15:28:01 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Daniel Kiper <daniel.kiper@...cle.com>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, bp@...en8.de, corbet@....net,
        dpsmith@...rtussolutions.com, eric.snowberg@...cle.com,
        kanth.ghatraju@...cle.com, konrad.wilk@...cle.com,
        mingo@...hat.com, ross.philipson@...cle.com, tglx@...utronix.de
Subject: Re: [PATCH v2 1/3] x86/boot: Introduce the kernel_info

On 2019-10-01 04:41, Daniel Kiper wrote:
> 
> OK, so, this is more or less what I had in my v3 patch before sending
> this email. So, it looks that I am on good track. Great! Though I am not
> sure that we should have magic for chunked objects. If yes could you
> explain why? I would just leave len for chunked objects.
> 

It makes it easier to validate the contents (bugs happen...), and would allow
for multiple chunks that could come from different object files if it ever
becomes necessary for some reason.

We could also just say that dynamic chunks don't even have pointers, and let
the boot loader just walk the list.

>> Also "InfO" is a pretty hideous magic. In general, all-ASCII magics have much
>> higher risk of collision than *RANDOM* binary numbers. However, for a chunked
>> architecture they do have the advantage that they can be used also as a human
>> name or file name for the chunk, e.,g. in sysfs, so maybe something like
>> "LnuX" or even "LToP" for the top-level chunk might make sense.
>>
>> How does that sound?
> 
> Well, your proposals are more cryptic, especially the second one, than
> mine but I tend to agree that more *RANDOM* magics are better. So,
> I would choose "LToP" if you decipher it for me. Linux Top?
> 

Yes, Linux top [structure].

	-hpa