linux-kernel - Re: [PATCH 0/3] bootconfig: Make size and checksum fields le32

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]

Date:   Wed, 2 Dec 2020 08:41:04 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Chen Yu <yu.c.chen@...el.com>,
        Chen Yu <yu.chen.surf@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [PATCH 0/3] bootconfig: Make size and checksum fields le32

On Tue, 1 Dec 2020 10:48:18 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Fri, 20 Nov 2020 11:28:55 +0900
> Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > Hello,
> > 
> > This is a series of patches to make the size and the checksum fields
> > in the footer le32 instead of u32.
> > 
> > In the thread for alignment series[1], Steve pointed that the current
> > footer format didn't specify the endianness thus it is hard to apply
> > the bootconfig for cross-build initrd if the target endianness is
> > different from the host machine.
> > 
> > I've proposed that the hexadecimal ASCII string in the previous series
> > [2] but Linus pointed that making it le32 was enough.
> > 
> > So this just make those fields le32.
> > 
> > Thank you,
> > 
> > [1] https://lore.kernel.org/lkml/20201118112249.30d20147@gandalf.local.home/
> > [2] https://lore.kernel.org/linux-doc/CAHk-=wi9RedSQoGF06dVs2mp7tBp4QoiW8+XZzNcDFJr3Zo5gg@mail.gmail.com/
> > 
> > ---
> > 
> 
> I have this all tested. Is this something that should go into the current
> -rc release, or wait for the next merge window?

Hrm, this kind of things usually good for the next merge window because
it is only for the different endianess cross-build case. But the next
release will be LTS (6 years life cycle), so it is possible someone
hits this issue before EOL and (I guess) finally they need this series.

So if possible, could you push this in -rc release? I think this doesn't
change so much.

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>