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]
Message-Id: <20201202084104.20d7f1223986d58a5547a662@kernel.org>
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>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ