All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Kosina <jikos@kernel.org>
To: Thomas Garnier <thgarnie@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM list <linux-pm@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Kees Cook <keescook@chromium.org>, Pavel Machek <pavel@ucw.cz>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Borislav Petkov <bpetkov@suse.de>
Subject: Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly
Date: Tue, 9 Aug 2016 17:05:36 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LNX.2.00.1608091702240.22028@cbobk.fhfr.pm> (raw)
In-Reply-To: <CAJcbSZHdTJC8ys-rhi19k+gmxe+U3m_e+i4aRTuuyV18r6ukCA@mail.gmail.com>

On Tue, 9 Aug 2016, Thomas Garnier wrote:

> >> Okay, I did one-by-one reverts, and the one above, i.e.
> >>
> >>       commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
> >>       Author: Thomas Garnier <thgarnie@google.com>
> >>       Date:   Tue Jun 21 17:47:03 2016 -0700
> >>
> >>           x86/mm: Enable KASLR for physical mapping memory regions
> >>
> >> is the one that is the culprit on my machine. With this one reverted,
> >> resume hibernation doesn't reboot (tripple fault?), but proceeds
> >> succesfully.
> 
> My .config is attached. It is basically defconfig (x86_64) + kvmconfig
> plus the following:
> 
> CONFIG_PHYSICAL_START=0x1000000
> CONFIG_RELOCATABLE=y
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_X86_NEED_RELOCS=y
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
> CONFIG_X86_PTDUMP_CORE=y
> CONFIG_X86_PTDUMP=y
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
> CONFIG_KALLSYMS_BASE_RELATIVE=y
> CONFIG_PANIC_ON_OOPS=y
> CONFIG_KGDB=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_EARLY_PRINTK_DBGP=y
> CONFIG_DEBUG_INFO=y
> CONFIG_DEBUG_INFO_DWARF4=y

The config I am reproducing the bug with (on thinkpad x200s) can be found 
at

	http://www.jikos.cz/jikos/junk/.config

Either later today or tomorrow I could test with the same physical start 
and align values you're using to see whether that'd make any difference.

> > As discussed with Rafael privately, I also tried this very patch
> > (x86/power/64: Always create temporary identity mapping correctly) on top
> > of the reverted revert of 021182e52fe01c1f7b1 (see the full log below),
> > but such kernel triple faults on resume as well.
> >
> > 87c38d2 x86/power/64: Always create temporary identity mapping correctly
> > 3cb504a Revert "Revert "x86/mm: Enable KASLR for physical mapping memory regions""
> > 758850d Revert "x86/mm: Enable KASLR for physical mapping memory regions"
> > 4a02dfb Revert "x86/mm: Enable KASLR for vmalloc memory regions"
> > 037863f Revert "x86/mm: Add memory hotplug support for KASLR memory randomization"
> > 3416a21 Revert "x86/mm: Do not reference phys addr beyond kernel"
> > 69227be Revert "mm: reorganize SLAB freelist randomization"
> > a1d8d71 Revert "mm: SLUB freelist randomization"
> >
> > IOW, 021182e52f introduces a bug for which there is no existing fix yet.
> 
> You mean it is something different from the previous KASLR bugs we saw?

No, I just wanted to explicitly point out that "x86/power/64: Always 
create temporary identity mapping correctly" is not a fix for this issue.

-- 
Jiri Kosina
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Jiri Kosina <jikos@kernel.org>
To: Thomas Garnier <thgarnie@google.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux PM list <linux-pm@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H . Peter Anvin" <hpa@zytor.com>,
	Kees Cook <keescook@chromium.org>, Pavel Machek <pavel@ucw.cz>,
	Kernel Hardening <kernel-hardening@lists.openwall.com>,
	Borislav Petkov <bpetkov@suse.de>
Subject: [kernel-hardening] Re: [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly
Date: Tue, 9 Aug 2016 17:05:36 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LNX.2.00.1608091702240.22028@cbobk.fhfr.pm> (raw)
In-Reply-To: <CAJcbSZHdTJC8ys-rhi19k+gmxe+U3m_e+i4aRTuuyV18r6ukCA@mail.gmail.com>

On Tue, 9 Aug 2016, Thomas Garnier wrote:

> >> Okay, I did one-by-one reverts, and the one above, i.e.
> >>
> >>       commit 021182e52fe01c1f7b126f97fd6ba048dc4234fd
> >>       Author: Thomas Garnier <thgarnie@google.com>
> >>       Date:   Tue Jun 21 17:47:03 2016 -0700
> >>
> >>           x86/mm: Enable KASLR for physical mapping memory regions
> >>
> >> is the one that is the culprit on my machine. With this one reverted,
> >> resume hibernation doesn't reboot (tripple fault?), but proceeds
> >> succesfully.
> 
> My .config is attached. It is basically defconfig (x86_64) + kvmconfig
> plus the following:
> 
> CONFIG_PHYSICAL_START=0x1000000
> CONFIG_RELOCATABLE=y
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_X86_NEED_RELOCS=y
> CONFIG_PHYSICAL_ALIGN=0x1000000
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
> CONFIG_X86_PTDUMP_CORE=y
> CONFIG_X86_PTDUMP=y
> CONFIG_KALLSYMS=y
> CONFIG_KALLSYMS_ALL=y
> CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
> CONFIG_KALLSYMS_BASE_RELATIVE=y
> CONFIG_PANIC_ON_OOPS=y
> CONFIG_KGDB=y
> CONFIG_EARLY_PRINTK=y
> CONFIG_EARLY_PRINTK_DBGP=y
> CONFIG_DEBUG_INFO=y
> CONFIG_DEBUG_INFO_DWARF4=y

The config I am reproducing the bug with (on thinkpad x200s) can be found 
at

	http://www.jikos.cz/jikos/junk/.config

Either later today or tomorrow I could test with the same physical start 
and align values you're using to see whether that'd make any difference.

> > As discussed with Rafael privately, I also tried this very patch
> > (x86/power/64: Always create temporary identity mapping correctly) on top
> > of the reverted revert of 021182e52fe01c1f7b1 (see the full log below),
> > but such kernel triple faults on resume as well.
> >
> > 87c38d2 x86/power/64: Always create temporary identity mapping correctly
> > 3cb504a Revert "Revert "x86/mm: Enable KASLR for physical mapping memory regions""
> > 758850d Revert "x86/mm: Enable KASLR for physical mapping memory regions"
> > 4a02dfb Revert "x86/mm: Enable KASLR for vmalloc memory regions"
> > 037863f Revert "x86/mm: Add memory hotplug support for KASLR memory randomization"
> > 3416a21 Revert "x86/mm: Do not reference phys addr beyond kernel"
> > 69227be Revert "mm: reorganize SLAB freelist randomization"
> > a1d8d71 Revert "mm: SLUB freelist randomization"
> >
> > IOW, 021182e52f introduces a bug for which there is no existing fix yet.
> 
> You mean it is something different from the previous KASLR bugs we saw?

No, I just wanted to explicitly point out that "x86/power/64: Always 
create temporary identity mapping correctly" is not a fix for this issue.

-- 
Jiri Kosina
SUSE Labs

  reply	other threads:[~2016-08-09 15:05 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-08 13:31 [Resend][PATCH] x86/power/64: Always create temporary identity mapping correctly Rafael J. Wysocki
2016-08-08 13:31 ` [kernel-hardening] " Rafael J. Wysocki
2016-08-08 13:40 ` Borislav Petkov
2016-08-08 13:40   ` [kernel-hardening] " Borislav Petkov
2016-08-08 13:54   ` Rafael J. Wysocki
2016-08-08 13:54     ` [kernel-hardening] " Rafael J. Wysocki
2016-08-08 18:00     ` Thomas Garnier
2016-08-08 18:00       ` [kernel-hardening] " Thomas Garnier
2016-08-08 20:01       ` Rafael J. Wysocki
2016-08-08 20:01         ` [kernel-hardening] " Rafael J. Wysocki
2016-08-09  7:02     ` Borislav Petkov
2016-08-09  7:02       ` [kernel-hardening] " Borislav Petkov
2016-08-09 11:47       ` Rafael J. Wysocki
2016-08-09 11:47         ` [kernel-hardening] " Rafael J. Wysocki
2016-08-09  9:23 ` Jiri Kosina
2016-08-09  9:23   ` [kernel-hardening] " Jiri Kosina
2016-08-09 11:56   ` Rafael J. Wysocki
2016-08-09 11:56     ` [kernel-hardening] " Rafael J. Wysocki
2016-08-09 12:58     ` Jiri Kosina
2016-08-09 12:58       ` [kernel-hardening] " Jiri Kosina
2016-08-09 13:30       ` Jiri Kosina
2016-08-09 13:30         ` [kernel-hardening] " Jiri Kosina
2016-08-09 15:00         ` Thomas Garnier
2016-08-09 15:00           ` [kernel-hardening] " Thomas Garnier
2016-08-09 15:05           ` Jiri Kosina [this message]
2016-08-09 15:05             ` Jiri Kosina
2016-08-09 16:18             ` Rafael J. Wysocki
2016-08-09 16:18               ` [kernel-hardening] " Rafael J. Wysocki
2016-08-09 16:27               ` Thomas Garnier
2016-08-09 16:27                 ` [kernel-hardening] " Thomas Garnier
2016-08-09 20:50                 ` Rafael J. Wysocki
2016-08-09 20:50                   ` [kernel-hardening] " Rafael J. Wysocki
2016-08-09 20:02               ` Jiri Kosina
2016-08-09 20:02                 ` [kernel-hardening] " Jiri Kosina
2016-08-09 21:23                 ` Rafael J. Wysocki
2016-08-09 21:23                   ` [kernel-hardening] " Rafael J. Wysocki
2016-08-10  0:21                   ` Rafael J. Wysocki
2016-08-10  0:21                     ` [kernel-hardening] " Rafael J. Wysocki
2016-08-10  7:50                     ` Jiri Kosina
2016-08-10  7:50                       ` [kernel-hardening] " Jiri Kosina
2016-08-10 13:11                       ` Rafael J. Wysocki
2016-08-10 13:11                         ` [kernel-hardening] " Rafael J. Wysocki
2016-08-10 13:18                         ` Jiri Kosina
2016-08-10 13:18                           ` [kernel-hardening] " Jiri Kosina
2016-08-10 14:42                           ` Thomas Garnier
2016-08-10 14:42                             ` [kernel-hardening] " Thomas Garnier
2016-08-10 14:59                             ` Jiri Kosina
2016-08-10 14:59                               ` [kernel-hardening] " Jiri Kosina
2016-08-10 16:35                               ` Borislav Petkov
2016-08-10 16:35                                 ` [kernel-hardening] " Borislav Petkov
2016-08-10 16:44                                 ` Thomas Garnier
2016-08-10 16:44                                   ` [kernel-hardening] " Thomas Garnier
2016-08-10 21:52                                   ` Jiri Kosina
2016-08-10 21:52                                     ` [kernel-hardening] " Jiri Kosina
2016-08-10 21:58                                     ` Rafael J. Wysocki
2016-08-10 21:58                                       ` [kernel-hardening] " Rafael J. Wysocki
2016-08-10 20:56                                 ` Rafael J. Wysocki
2016-08-10 20:56                                   ` [kernel-hardening] " Rafael J. Wysocki
2016-08-10 21:13                                   ` Rafael J. Wysocki
2016-08-10 21:13                                     ` [kernel-hardening] " Rafael J. Wysocki
2016-08-10 21:59                                     ` Jiri Kosina
2016-08-10 21:59                                       ` [kernel-hardening] " Jiri Kosina
2016-08-11  0:35                                       ` Rafael J. Wysocki
2016-08-11  0:35                                         ` [kernel-hardening] " Rafael J. Wysocki
2016-08-11  1:17                                         ` Thomas Garnier
2016-08-11  1:17                                           ` [kernel-hardening] " Thomas Garnier
2016-08-11  1:35                                           ` Rafael J. Wysocki
2016-08-11  1:35                                             ` [kernel-hardening] " Rafael J. Wysocki
2016-08-11 18:47                                             ` Thomas Garnier
2016-08-11 18:47                                               ` [kernel-hardening] " Thomas Garnier
2016-08-11 21:33                                               ` Rafael J. Wysocki
2016-08-11 21:33                                                 ` [kernel-hardening] " Rafael J. Wysocki
2016-08-11 21:32                                                 ` Thomas Garnier
2016-08-11 21:32                                                   ` [kernel-hardening] " Thomas Garnier

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=alpine.LNX.2.00.1608091702240.22028@cbobk.fhfr.pm \
    --to=jikos@kernel.org \
    --cc=bpetkov@suse.de \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=thgarnie@google.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.