From: Baoquan He <bhe@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
keescook@chromium.org, matt@codeblueprint.co.uk,
tglx@linutronix.de, hpa@zytor.com, izumi.taku@jp.fujitsu.com,
fanc.fnst@cn.fujitsu.com, thgarnie@google.com,
n-horiguchi@ah.jp.nec.com
Subject: Re: [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions
Date: Fri, 21 Jul 2017 21:19:56 +0800 [thread overview]
Message-ID: <20170721131956.GK2344@x1> (raw)
In-Reply-To: <20170721103757.hc74czr3mfunrv6c@gmail.com>
On 07/21/17 at 12:37pm, Ingo Molnar wrote:
>
> * Baoquan He <bhe@redhat.com> wrote:
>
> > +/*
> > + * Returns true if mirror region found (and must have been processed
> > + * for slots adding)
> > + */
> > +static bool process_efi_entries(unsigned long minimum,
> > + unsigned long image_size)
>
> Also, please don't break the line in the middle of the prototype.
OK, will change it into oneline. I worry it's a little too long since
it's 80 chars wide if not break.
>
> > +{
> > + struct efi_info *e = &boot_params->efi_info;
> > + bool efi_mirror_found = false;
> > + struct mem_vector region;
> > + efi_memory_desc_t *md;
> > + unsigned long pmap;
> > + char *signature;
> > + u32 nr_desc;
> > + int i;
> > +
> > + signature = (char *)&boot_params->efi_info.efi_loader_signature;
>
> This is sloppy too: we already have '&boot_params->efi_info' in 'e', why do you
> duplicate it again, why not write 'e->efi_loader_signature'??
Right, will change.
>
> > + if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
> > + strncmp(signature, EFI64_LOADER_SIGNATURE, 4))
> > + return false;
> > +
> > +#ifdef CONFIG_X86_32
> > + /* Can't handle data above 4GB at this time */
> > + if (e->efi_memmap_hi) {
> > + warn("Memory map is above 4GB, EFI should be disabled.\n");
> > + return false;
>
> This kernel warning is pretty passive-aggressive: please explain what the problem
> is and how it can be resolved.
Maybe it can be like :
warn("Data above 4G can't be handled now in 32bit system, EFI should be disabled.\n");
> > + return false;
>
> > + }
> > + pmap = e->efi_memmap;
> > +#else
> > + pmap = (e->efi_memmap | ((__u64)e->efi_memmap_hi << 32));
> > +#endif
> > +
> > + nr_desc = e->efi_memmap_size / e->efi_memdesc_size;
> > + for (i = 0; i < nr_desc; i++) {
> > + md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
>
> This looks unnecessarily obfuscated: why not initialize 'md' to 'pmap' when pmap
> is calculated and just use md[i]?
There are places where the efi map is getting and used like this. E.g
in efi_high_alloc() of drivers/firmware/efi/libstub/efi-stub-helper.c.
EFI developers worry the size of efi_memory_desc_t could not be the same
as e->efi_memdesc_size?
Hi Matt,
Could you help have a look at this?
>
> > +static inline bool process_efi_entries(unsigned long minimum,
> > + unsigned long image_size)
>
> ugly linebreak again ...
The whole line is more than 80. I break the line and use tab and space
to make it align with above 'unsigned long minimum'. Don't know why it
becomes messy in patch. Will check and try again.
Thanks
Baoquan
next prev parent reply other threads:[~2017-07-21 13:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-20 9:16 [PATCH v6 RESEND] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions Baoquan He
2017-07-21 10:33 ` Ingo Molnar
2017-07-21 12:35 ` Baoquan He
2017-07-21 10:37 ` Ingo Molnar
2017-07-21 13:19 ` Baoquan He [this message]
2017-07-21 17:37 ` Ingo Molnar
2017-07-21 23:43 ` Baoquan He
2017-07-24 13:34 ` Matt Fleming
2017-07-25 0:23 ` Baoquan He
2017-07-28 8:06 ` Baoquan He
2017-07-28 9:55 ` Ingo Molnar
2017-07-28 10:18 ` Baoquan He
2017-07-28 10:38 ` Baoquan He
2017-07-28 11:26 ` Baoquan He
2017-08-04 11:23 ` Matt Fleming
2017-08-04 11:40 ` Baoquan He
2017-08-04 11:55 ` Matt Fleming
2017-08-04 12:02 ` Baoquan He
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=20170721131956.GK2344@x1 \
--to=bhe@redhat.com \
--cc=fanc.fnst@cn.fujitsu.com \
--cc=hpa@zytor.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=x86@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