From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@redhat.com>,
LKML <linux-kernel@vger.kernel.org>, Baoquan He <bhe@redhat.com>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
lasse.collin@tukaani.org,
Andrew Morton <akpm@linux-foundation.org>,
Dave Young <dyoung@redhat.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Subject: [kernel-hardening] Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support
Date: Wed, 13 Apr 2016 12:19:50 +0200 [thread overview]
Message-ID: <20160413101950.GC9482@gmail.com> (raw)
In-Reply-To: <CAGXu5jKtXndmfLNt1PZvL1oE5BXHDHsAcGBy=0V-nHg=6CA8HA@mail.gmail.com>
* Kees Cook <keescook@chromium.org> wrote:
> FWIW, I've also had this tree up in my git branches, and the 0day
> tester hasn't complained at all about it in the last two weeks. I'd
> really like to see this in -next to fix the >4G (mainly kexec) issues
> and get us to feature parity with the arm64 kASLR work (randomized
> virtual address).
So I started applying the patches, started fixing up changelogs and gave up on
patch #3.
Changelogs of such non-trivial code need to be proper English and need to be
understandable.
For example patch #3 starts with:
> Current z_extract_offset is calculated in boot/compressed/mkpiggy.c. The problem
> is in mkpiggy.c we don't know the detail of decompressor. Then we just get a
> rough z_extract_offset according to extra_bytes. As we know extra_bytes can only
> promise a safety margin when decompressing. In fact this brings some risks:
Beyond the bad grammar of the _first word_ of the changelog, this is not a proper
high level description of the change. A _real_ high level description would be
something like:
> Currently z_extract_offset is calculated during kernel build time. The problem
> with that method is that at this stage we don't yet know the decompression
> buffer sizes - we only know that during bootup.
>
> Effects of this are that when we calculate z_extract_offset during the build
> we don't know the precise decompression details, we'll only get a rough
> estimation of z_extract_offset.
>
> Instead of that we want to calculate it during bootup.
etc. etc. - the whole series is _full_ of such crappy changelogs that make it
difficult for me and others to see whether the author actually _understands_ the
existing code or is hacking away on it. It's also much harder to review and
validate.
This is totally unacceptable.
Please make sure every changelog starts with a proper high level description that
tells the story and convinces the reader about what the problem is and what the
change should be.
And part of that are the patch titles. Things like:
Subject: [PATCH v3 03/19] x86, boot: Move z_extract_offset calculation to header.S
are absolutely mindless titles. A better title would be:
x86/boot: Calculate precise decompressor parameters during bootup, not build time
... or something like that. Even having read the changelog 3 times I'm unsure what
the change really is about.
Thanks,
Ingo
next prev parent reply other threads:[~2016-04-13 10:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1458631937-14593-1-git-send-email-bhe@redhat.com>
[not found] ` <20160405015613.GA4654@x1.redhat.com>
2016-04-05 20:00 ` [kernel-hardening] Re: [PATCH v4 00/20] x86, boot: kaslr cleanup and 64bit kaslr support Kees Cook
2016-04-13 10:19 ` Ingo Molnar [this message]
2016-04-13 14:11 ` Kees Cook
2016-04-14 6:02 ` Kees Cook
2016-04-14 6:24 ` Baoquan He
2016-04-14 15:06 ` Baoquan He
2016-04-14 17:56 ` Kees Cook
2016-04-15 4:08 ` Baoquan He
2016-04-15 4:52 ` Kees Cook
2016-04-15 6:55 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160413101950.GC9482@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=lasse.collin@tukaani.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox