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: <1520518288.18140.14.camel@nxp.com>
Date:   Thu, 8 Mar 2018 16:11:28 +0200
From:   Leonard Crestez <leonard.crestez@....com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
CC:     Herbert Xu <herbert@...dor.apana.org.au>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: arm crypto .S_shipped files sometimes get rebuilt randomly

On Thu, 2018-03-08 at 07:02 +0000, Ard Biesheuvel wrote:
> On 8 March 2018 at 05:00, Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:
> > 2018-03-08 4:25 GMT+09:00 Leonard Crestez <leonard.crestez@....com

> > > If a decision to rerun the rule is made based on their relative
> > > timestamps but both .S_shipped and sha512-armv8.pl are included in git
> > > then won't the result be essentially random, depending on file checkout
> > > order?

> I agree with your analysis, although  I never see these spurious
> rebuilds of these files.

It would happen at most once per checkout since after it happens the
timestamp on .S_shipped is updated. An extra line in make output is
very easy to miss.

> > We have two choices.
> > 
> > [1] If we intend to generate
> > sha{256,512}-core.S from the perl script during the build,
> > this should be:
> > 
> > [2] If we want to check-in _shipped files
> > and avoid running perl during the build,
> > we can surround unnecessary rules with if-conditional, like
> > 
> > Recently, Kconfig switched to [1].
> > So, flex and bison are required to build the kernel.

> I would prefer option [1], but only if it is already documented
> somewhere that Perl is a build time dependency.

This already seems to be the case, in Documentation/process/changes.rst

> You will need perl 5 and the following modules: ``Getopt::Long``,
> ``Getopt::Std``, ``File::Basename``, and ``File::Find`` to build the
> kernel.

Maybe "integer.pm" would need to be explicitly documented as a
dependency as well? I don't know anything about the perl ecosystem.

Building the kernel with make PERL=/bin/false seems to mostly work
though, it's used for stuff like docs and headers_check (which is not
enabled by default).

--
Regards,
Leonard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ