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: <20211228170308.1454063-1-alexandr.lobakin@intel.com>
Date:   Tue, 28 Dec 2021 18:03:08 +0100
From:   Alexander Lobakin <alexandr.lobakin@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Alexander Lobakin <alexandr.lobakin@...el.com>,
        linux-hardening@...r.kernel.org, x86@...nel.org,
        Jesse Brandeburg <jesse.brandeburg@...el.com>,
        Kristen Carlson Accardi <kristen@...ux.intel.com>,
        Kees Cook <keescook@...omium.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        Ard Biesheuvel <ardb@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Bruce Schlobohm <bruce.schlobohm@...el.com>,
        Jessica Yu <jeyu@...nel.org>,
        kernel test robot <lkp@...el.com>,
        Miroslav Benes <mbenes@...e.cz>,
        Evgenii Shatokhin <eshatokhin@...tuozzo.com>,
        Jonathan Corbet <corbet@....net>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Will Deacon <will@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnd Bergmann <arnd@...db.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Marios Pomonis <pomonis@...gle.com>,
        Sami Tolvanen <samitolvanen@...gle.com>,
        "H.J. Lu" <hjl.tools@...il.com>, Nicolas Pitre <nico@...xnic.net>,
        linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
        linux-arch@...r.kernel.org, live-patching@...r.kernel.org,
        llvm@...ts.linux.dev, stable@...r.kernel.org
Subject: Re: [PATCH v9 01/15] modpost: fix removing numeric suffixes

From: Borislav Petkov <bp@...en8.de>
Date: Mon, 27 Dec 2021 22:26:02 +0100

> On Mon, Dec 27, 2021 at 07:22:46PM +0100, Alexander Lobakin wrote:
> > It's just a couple lines below. I trigger this using `-z uniq-symbol`
> > which uses numeric suffixes for globals as well.
> 
> Aha, so that's for the fgkaslr purposes now.

Well, linking using unique names is meant to be used always
when available and livepatching is enabled, at least I hope so.

> 
> > It fixes a commit dated 2014, thus Cc:stable. Although the
> > remove_dot() might've been introduced for neverlanded GCC LTO, but
> > in fact numeric suffixes are used a lot by the toolchains in regular
> > builds as well. Just not for globals, that's why it's "well hidden".
> 
> Does "well hidden" warrant a stable backport then? Because if no
> toolchain is using numeric suffixes for globals, then no need for the
> stable tag, I'd say.

Hmm, makes sense. The fact that I haven't seen any similar reports
or issues (even on LTO builds) sorta says there are no benefits from
backporting this.
Ok, I'll drop the tag. It's never too late anyway to port this in
case someone will face it.

> 
> > I thought it's a common saying in commit messages, isn't it?
> 
> Lemme give you my canned and a lot more eloquent explanation for that:
> 
> "Please use passive voice in your commit message: no "we" or "I", etc,
> and describe your changes in imperative mood.
> 
> Also, pls read section "2) Describe your changes" in
> Documentation/process/submitting-patches.rst for more details.
> 
> Also, see section "Changelog" in
> Documentation/process/maintainer-tip.rst
> 
> Bottom line is: personal pronouns are ambiguous in text, especially with
> so many parties/companies/etc developing the kernel so let's avoid them
> please."
> 
> Thx.

Ah, you're right. "Common used" doesn't mean "correct". I'll fix it
in the next spin being published after accumulating a bunch more
comments.
Thanks!

> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

Al

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ