All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Yinghai Lu <yinghai@kernel.org>, Baoquan He <bhe@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Matt Redfearn <matt.redfearn@imgtec.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@redhat.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,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v5 01/21] x86, KASLR: Remove unneeded boot_params argument
Date: Fri, 15 Apr 2016 09:29:40 +0200	[thread overview]
Message-ID: <20160415072940.GB30715@gmail.com> (raw)
In-Reply-To: <1460672954-32567-2-git-send-email-keescook@chromium.org>


* Kees Cook <keescook@chromium.org> wrote:

> From: Yinghai Lu <yinghai@kernel.org>
> 
> Since the boot_params can be found using the real_mode global variable, there is 
> no need to pass around a pointer to it. This slightly simplifies the 
> choose_kernel_location function and its callers.

Yeah, so I really wanted to apply this series because the changelogs are now very 
nice, but got held up by the very first patch again ...

Guys, 'real_mode' totally sucks as a variable name!

By removing a seemingly unnecessary parameter, you made the code actively worse to 
read...

So please make a second patch on top of this one that renames 'real_mode' to 
something that both displays what it is about (it sure isn't mainly about real 
mode only!!), and also expresses that it's a global variable, not some local 
function parameter.

In arch/x86/ we usually achieve that via prefixing it with x86_ or so. So 
something like 'x86_boot_params' would work for me. I realize that this is 
somewhat special, because this is pre-relocation code so we really have to be 
careful about pointers - so maybe name it x86_boot_params_rm or so.

Also, I had a look at the whole file you are patching, 
arch/x86/boot/compressed/misc.c, and for heaven's sake, please first improve the 
comments on top of that file before further complicating that code with KASLR 
details! Right now it consists of various low level ramblings choke full of typos. 
No mention of where KASLR fits into the picture at all!

Right now it says:

 * misc.c
 *
 * This is a collection of several routines from gzip-1.0.3
 * adapted for Linux.

Which was perhaps true 15 years ago, but sure it's not true today! We do 
relocation and KASLR processing in this path as well, which is just as important 
as running the decompressor. Also, gzip is not the only decompressor we support.

The high level purpose of the code in this file should be explained first, and the 
file should probably be renamed to something like extract.c - to signal that this 
file is about extracting a kernel image and preparing it for execution (i.e. 
relinking it, etc.). It's (much!) more than just pure decompression.

Likewise, decompress_kernel() should be renamed to extract_kernel().

The low level explanations in extract.c should be moved to the function that is 
affected by those details. The top of the file should only contain general 
explanations, a high level description of in what state the kernel is when we call 
this code, and the sort of stuff we do in that code.

The credits should be collected into a single, coherent block. Unnecessary fluff 
should be cut.

Furthermore, I see similar problems with arch/x86/boot/compressed/aslr.c: for 
example it has no high level description at the top of the file _at all_. WTF is 
this with writing security-sensitive code that has no high level design 
description whatsoever?? Also, why is it named aslr.c, why not kaslr.c? We do have 
both KASLR and ASLR code in the kernel, confusing naming on the source code level 
sure does not help.

Also, what's this thing about choose_kernel_location()? That name is actively 
hiding the fact that the main purpose of that function is to randomize things ... 

It should be named x86_randomize_kernel_address() or so.

We need to stop making a mess of the x86 boot code! This is a highly critical 
piece of kernel code that every single x86 Linux user will execute, we should 
improve its visual presentation and general readability to the level of being 
proud of it ...

Thanks,

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Yinghai Lu <yinghai@kernel.org>, Baoquan He <bhe@redhat.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Matt Redfearn <matt.redfearn@imgtec.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@redhat.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,
	LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [kernel-hardening] Re: [PATCH v5 01/21] x86, KASLR: Remove unneeded boot_params argument
Date: Fri, 15 Apr 2016 09:29:40 +0200	[thread overview]
Message-ID: <20160415072940.GB30715@gmail.com> (raw)
In-Reply-To: <1460672954-32567-2-git-send-email-keescook@chromium.org>


* Kees Cook <keescook@chromium.org> wrote:

> From: Yinghai Lu <yinghai@kernel.org>
> 
> Since the boot_params can be found using the real_mode global variable, there is 
> no need to pass around a pointer to it. This slightly simplifies the 
> choose_kernel_location function and its callers.

Yeah, so I really wanted to apply this series because the changelogs are now very 
nice, but got held up by the very first patch again ...

Guys, 'real_mode' totally sucks as a variable name!

By removing a seemingly unnecessary parameter, you made the code actively worse to 
read...

So please make a second patch on top of this one that renames 'real_mode' to 
something that both displays what it is about (it sure isn't mainly about real 
mode only!!), and also expresses that it's a global variable, not some local 
function parameter.

In arch/x86/ we usually achieve that via prefixing it with x86_ or so. So 
something like 'x86_boot_params' would work for me. I realize that this is 
somewhat special, because this is pre-relocation code so we really have to be 
careful about pointers - so maybe name it x86_boot_params_rm or so.

Also, I had a look at the whole file you are patching, 
arch/x86/boot/compressed/misc.c, and for heaven's sake, please first improve the 
comments on top of that file before further complicating that code with KASLR 
details! Right now it consists of various low level ramblings choke full of typos. 
No mention of where KASLR fits into the picture at all!

Right now it says:

 * misc.c
 *
 * This is a collection of several routines from gzip-1.0.3
 * adapted for Linux.

Which was perhaps true 15 years ago, but sure it's not true today! We do 
relocation and KASLR processing in this path as well, which is just as important 
as running the decompressor. Also, gzip is not the only decompressor we support.

The high level purpose of the code in this file should be explained first, and the 
file should probably be renamed to something like extract.c - to signal that this 
file is about extracting a kernel image and preparing it for execution (i.e. 
relinking it, etc.). It's (much!) more than just pure decompression.

Likewise, decompress_kernel() should be renamed to extract_kernel().

The low level explanations in extract.c should be moved to the function that is 
affected by those details. The top of the file should only contain general 
explanations, a high level description of in what state the kernel is when we call 
this code, and the sort of stuff we do in that code.

The credits should be collected into a single, coherent block. Unnecessary fluff 
should be cut.

Furthermore, I see similar problems with arch/x86/boot/compressed/aslr.c: for 
example it has no high level description at the top of the file _at all_. WTF is 
this with writing security-sensitive code that has no high level design 
description whatsoever?? Also, why is it named aslr.c, why not kaslr.c? We do have 
both KASLR and ASLR code in the kernel, confusing naming on the source code level 
sure does not help.

Also, what's this thing about choose_kernel_location()? That name is actively 
hiding the fact that the main purpose of that function is to randomize things ... 

It should be named x86_randomize_kernel_address() or so.

We need to stop making a mess of the x86 boot code! This is a highly critical 
piece of kernel code that every single x86 Linux user will execute, we should 
improve its visual presentation and general readability to the level of being 
proud of it ...

Thanks,

	Ingo

  reply	other threads:[~2016-04-15  7:29 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 22:28 [PATCH v5 00/21] x86, boot: KASLR cleanup and 64-bit improvements Kees Cook
2016-04-14 22:28 ` [kernel-hardening] " Kees Cook
2016-04-14 22:28 ` [PATCH v5 01/21] x86, KASLR: Remove unneeded boot_params argument Kees Cook
2016-04-14 22:28   ` [kernel-hardening] " Kees Cook
2016-04-15  7:29   ` Ingo Molnar [this message]
2016-04-15  7:29     ` [kernel-hardening] " Ingo Molnar
2016-04-15 18:55     ` Kees Cook
2016-04-15 18:55       ` [kernel-hardening] " Kees Cook
2016-04-14 22:28 ` [PATCH v5 02/21] x86, KASLR: Handle kernel relocation above 2G Kees Cook
2016-04-14 22:28   ` [kernel-hardening] " Kees Cook
2016-04-15  7:47   ` Ingo Molnar
2016-04-15  7:47     ` [kernel-hardening] " Ingo Molnar
2016-04-15 19:01     ` Kees Cook
2016-04-15 19:01       ` [kernel-hardening] " Kees Cook
2016-04-14 22:28 ` [PATCH v5 03/21] x86, KASLR: Drop CONFIG_RANDOMIZE_BASE_MAX_OFFSET Kees Cook
2016-04-14 22:28   ` [kernel-hardening] " Kees Cook
2016-04-15  8:07   ` Ingo Molnar
2016-04-15  8:07     ` [kernel-hardening] " Ingo Molnar
2016-04-15 19:12     ` Kees Cook
2016-04-15 19:12       ` [kernel-hardening] " Kees Cook
2016-04-16  8:42       ` Ingo Molnar
2016-04-16  8:42         ` [kernel-hardening] " Ingo Molnar
2016-04-14 22:28 ` [PATCH v5 04/21] x86, boot: Move compressed kernel to end of decompression buffer Kees Cook
2016-04-14 22:28   ` [kernel-hardening] " Kees Cook
2016-04-15  8:09   ` Ingo Molnar
2016-04-15  8:09     ` [kernel-hardening] " Ingo Molnar
2016-04-18 16:50     ` Kees Cook
2016-04-18 16:50       ` [kernel-hardening] " Kees Cook
2016-04-15  9:05   ` Ingo Molnar
2016-04-15  9:05     ` [kernel-hardening] " Ingo Molnar
2016-04-14 22:28 ` [PATCH v5 05/21] x86, boot: Calculate decompression size during boot not build Kees Cook
2016-04-14 22:28   ` [kernel-hardening] " Kees Cook
2016-04-15  8:12   ` Ingo Molnar
2016-04-15  8:12     ` [kernel-hardening] " Ingo Molnar
2016-04-15 19:14     ` Kees Cook
2016-04-15 19:14       ` [kernel-hardening] " Kees Cook
2016-04-14 22:28 ` [PATCH v5 06/21] x86, KASLR: Update description for decompressor worst case size Kees Cook
2016-04-14 22:28   ` [kernel-hardening] " Kees Cook
2016-04-15 16:17   ` Lasse Collin
2016-04-15 16:17     ` [kernel-hardening] " Lasse Collin
2016-04-14 22:29 ` [PATCH v5 07/21] x86, boot: Fix run_size calculation Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-15  8:31   ` Ingo Molnar
2016-04-15  8:31     ` [kernel-hardening] " Ingo Molnar
2016-04-15 19:26     ` Kees Cook
2016-04-15 19:26       ` [kernel-hardening] " Kees Cook
2016-04-16  9:00       ` Ingo Molnar
2016-04-16  9:00         ` [kernel-hardening] " Ingo Molnar
2016-04-14 22:29 ` [PATCH v5 08/21] x86, KASLR: Clean up unused code from old run_size Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 09/21] x86, KASLR: Correctly bounds-check relocations Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 10/21] x86, KASLR: Consolidate mem_avoid entries Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 11/21] x86, boot: Split out kernel_ident_mapping_init Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 12/21] x86, 64bit: Set ident_mapping for KASLR Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 13/21] x86, boot: Report overlap failures in memcpy Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-15 14:42   ` Lasse Collin
2016-04-15 14:42     ` [kernel-hardening] " Lasse Collin
2016-04-15 19:28     ` Kees Cook
2016-04-15 19:28       ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 14/21] x86, KASLR: Add slot_area to manage random slots Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 15/21] x86, KASLR: Add slot_area support functions Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 16/21] x86, KASLR: Add virtual address choosing function Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 17/21] x86, KASLR: Clarify purpose of each get_random_long Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 18/21] x86, KASLR: Randomize virtual address separately Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 19/21] x86, KASLR: Add physical address randomization >4G Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 20/21] x86, KASLR: Remove unused slot tracking code Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook
2016-04-14 22:29 ` [PATCH v5 21/21] x86, KASLR: Allow randomization below load address Kees Cook
2016-04-14 22:29   ` [kernel-hardening] " Kees Cook

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=20160415072940.GB30715@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.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=matt.redfearn@imgtec.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.