Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Emrah Demir <ed@abdsec.com>
To: Freeman Zhang <freeman.zhang1992@gmail.com>
Cc: kexec@lists.infradead.org, torvalds@linux-foundation.org
Subject: Re: Removal of the kernel code/data/bss resources does break kexec/kdump
Date: Thu, 14 Apr 2016 07:07:43 -0400	[thread overview]
Message-ID: <2f4d7dee6bb0e4afdc05f2b7457fcf79@abdsec.com> (raw)
In-Reply-To: <570F6D99.6090400@gmail.com>

On 2016-04-14 06:14, Freeman Zhang wrote:
> Mr. Torvalds,
> 
> I do notice your recent commit:
> 
>> commit c4004b02f8e5b9ce357a0bb1641756cc86962664
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Wed Apr 6 13:45:07 2016 -0700
>> 
>>     x86: remove the kernel code/data/bss resources from /proc/iomem
>> 
>> Let's see if anybody even notices.  I doubt anybody uses this, and it
>> does expose addresses that should be randomized, so let's just remove
>> the code.  It's old and traditional, and it used to be cute, but we
>> should have removed this long ago.
>> 
>> If it turns out anybody notices and this breaks something, we'll have 
>> to
>> revert this, and maybe we'll end up using other approaches instead
>> (using %pK or similar).  But removing unnecessary code is always the
>> preferred option.
> 
> Removal of these information causes 'kexec/kdump' to fail in the newer
> kernel, as 'kexec/arch/i386/crashdump-x86.c' is coded this way:
> 
> 
> /* Read kernel physical load addr from the file returned by 
> proc_iomem()
>  * (Kernel Code) and store in kexec_info */
> static int get_kernel_paddr(struct kexec_info *UNUSED(info),
>                             struct crash_elf_info *elf_info)
> {
>                ...
> 
>       if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
>               elf_info->kern_paddr_start = start;
>               dbgprintf("kernel load physical addr start = 0x%016Lx\n",
>                         (unsigned long long)start);
>               return 0;
>       }
> 
>      fprintf(stderr, "Cannot determine kernel physical load addr\n");
>      return -1;
> }
> 
> 
> Should we revert this commit, or update kexec/kdump code?
> 

Ubuntu also has some issues with this patch. I think there are several 
issue that hasn't been noticed.
It would be better you to revert this patch. Updating kexec/kdump might 
not solve this problem.

Kees Cook proposed to write a %pK formatted patch. This would solve most 
of the problems.

https://lkml.org/lkml/2016/4/14/18

Best regards!
Emrah Demir

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2016-04-14 11:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 10:14 Removal of the kernel code/data/bss resources does break kexec/kdump Freeman Zhang
2016-04-14 11:07 ` Emrah Demir [this message]
2016-04-14 17:40   ` Linus Torvalds
2016-04-14 20:27     ` Emrah Demir
2016-04-15  1:02       ` Linus Torvalds
2016-04-15  4:41         ` Kees Cook
2016-04-15 15:46           ` Emrah Demir
2016-04-15 16:48             ` Linus Torvalds
2016-04-15 17:08               ` Emrah Demir
2016-04-19  9:04         ` Dave Young
2016-04-19 16:20           ` Linus Torvalds
2016-04-20  1:13             ` Dave Young
2016-04-14 11:26 ` 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=2f4d7dee6bb0e4afdc05f2b7457fcf79@abdsec.com \
    --to=ed@abdsec.com \
    --cc=freeman.zhang1992@gmail.com \
    --cc=kexec@lists.infradead.org \
    --cc=torvalds@linux-foundation.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