All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Thomas Garnier <thgarnie@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Borislav Petkov <bp@suse.de>,
	Juergen Gross <jgross@suse.com>,
	Matt Fleming <matt@codeblueprint.co.uk>,
	Toshi Kani <toshi.kani@hpe.com>, Baoquan He <bhe@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Alexander Kuleshov <kuleshovmail@gmail.com>,
	Alexander Popov <alpopov@ptsecurity.com>,
	Joerg Roedel <jroedel@suse.de>, Dave Young <dyoung@redhat.com>,
	Lv Zheng <lv.zheng@intel.com>, Mark Salter <msalter@redhat.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Dmitry Vyukov <dvyukov@google.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Rientjes <rientjes@google.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Jan Beulich <JBeulich@suse.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Seth Jennings <sjennings@variantweb.net>,
	Yinghai Lu <yinghai@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 1/3] x86/mm: PUD VA support for physical mapping (x86_64)
Date: Fri, 17 Jun 2016 11:02:13 +0200	[thread overview]
Message-ID: <20160617090213.GC4791@gmail.com> (raw)
In-Reply-To: <1464217055-17654-2-git-send-email-keescook@chromium.org>


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

> From: Thomas Garnier <thgarnie@google.com>
> 
> Minor change that allows early boot physical mapping of PUD level virtual
> addresses. The current implementation expects the virtual address to be
> PUD aligned. For KASLR memory randomization, we need to be able to
> randomize the offset used on the PUD table.
> 
> It has no impact on current usage.
> 
> Signed-off-by: Thomas Garnier <thgarnie@google.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  arch/x86/mm/init_64.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index bce2e5d9edd4..f205f39bd808 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -454,10 +454,10 @@ phys_pud_init(pud_t *pud_page, unsigned long addr, unsigned long end,
>  {
>  	unsigned long pages = 0, next;
>  	unsigned long last_map_addr = end;
> -	int i = pud_index(addr);
> +	int i = pud_index((unsigned long)__va(addr));
>
>  
>  	for (; i < PTRS_PER_PUD; i++, addr = next) {
> -		pud_t *pud = pud_page + pud_index(addr);
> +		pud_t *pud = pud_page + pud_index((unsigned long)__va(addr));
>  		pmd_t *pmd;
>  		pgprot_t prot = PAGE_KERNEL;

So I really dislike two things about this code.

Firstly a pre-existing problem is that the parameter names to phys_pud_init() 
suck:

static unsigned long __meminit
phys_pud_init(pud_t *pud_page, unsigned long addr, unsigned long end,
                         unsigned long page_size_mask)

so 'unsigned long addr' is usually the signature of a virtual address - but that's 
no true here: it's a physical address.

Same goes for 'unsigned long end'. Plus it's unclear what the connection between 
'addr' and 'end' - it's not at all obvious 'at a glance' that they are the start 
and end addresses of a physical memory range.

All of these problems can be solved by renaming them to 'paddr_start' and 
'paddr_end'.

Btw., I believe this misnomer and confusing code resulted in the buggy 
'pud_index(addr)' not being noticed to begin with ...

Secondly, and that's a new problem introduced by this patch:

> +	int i = pud_index((unsigned long)__va(addr));
> +		pud_t *pud = pud_page + pud_index((unsigned long)__va(addr));

... beyond the repetition, using type casts is fragile. Type casts should be a red 
flag to anyone involved in low level, security relevant code! So I'm pretty 
unhappy about seeing such a problem in such a patch.

This code should be doing something like:

	unsigned long vaddr_start = __va(paddr_start);

... which gets rid of the type cast, the repetition and documents the code much 
better as well. Also see how easily the connection between the variables is 
self-documented just by picking names carefully:

	paddr_start
	paddr_end
	vaddr_start
	vaddr_end

Also, _please_ add a comment to phys_pud_init() that explains what the function 
does.

Thanks,

	Ingo

  reply	other threads:[~2016-06-17  9:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-25 22:57 [PATCH v6 0/3] x86/mm: memory area address KASLR Kees Cook
2016-05-25 22:57 ` [PATCH v6 1/3] x86/mm: PUD VA support for physical mapping (x86_64) Kees Cook
2016-06-17  9:02   ` Ingo Molnar [this message]
2016-06-20 16:17     ` Thomas Garnier
2016-06-21  8:18       ` Ingo Molnar
2016-05-25 22:57 ` [PATCH v6 2/3] x86/mm: Implement ASLR for kernel memory sections (x86_64) Kees Cook
2016-06-17 10:26   ` Ingo Molnar
2016-06-17 17:29     ` Kees Cook
2016-06-21 16:46     ` Thomas Garnier
2016-05-25 22:57 ` [PATCH v6 3/3] x86/mm: Memory hotplug support for KASLR memory randomization 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=20160617090213.GC4791@gmail.com \
    --to=mingo@kernel.org \
    --cc=JBeulich@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=alpopov@ptsecurity.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=bhe@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=borntraeger@de.ibm.com \
    --cc=bp@suse.de \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=dyoung@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=jroedel@suse.de \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kuleshovmail@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=lv.zheng@intel.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=mingo@redhat.com \
    --cc=msalter@redhat.com \
    --cc=rientjes@google.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=sds@tycho.nsa.gov \
    --cc=sjennings@variantweb.net \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.com \
    --cc=toshi.kani@hpe.com \
    --cc=wangkefeng.wang@huawei.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.