linux-kernel - Re: [GIT PULL] x86/uapi for 3.8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFxi5SnacGoHzHuth4PvTRQQWA5kWM+D2Mn+FgV4VGYADQ@mail.gmail.com>
Date:	Sat, 15 Dec 2012 11:58:00 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Jan Beulich <jbeulich@...e.com>,
	Matt Fleming <matt.fleming@...el.com>,
	David Howells <dhowells@...hat.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Arnd Bergmann <arnd@...db.de>, Dave Jones <davej@...hat.com>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] x86/uapi for 3.8

On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin <hpa@...or.com> wrote:
>
> Matt is on vacation, and I'm partly offline for the weekend, but that
> definitely seems suspicious.  Do we have a memory map of the affected
> machine(s)?

Here's mine.

  e820: BIOS-provided physical RAM map:
  BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
  BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
  BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
  BIOS-e820: [mem 0x0000000000100000-0x00000000bdc6ffff] usable
  BIOS-e820: [mem 0x00000000bdc70000-0x00000000bdc87fff] ACPI data
  BIOS-e820: [mem 0x00000000bdc88000-0x00000000bdcdbfff] ACPI NVS
  BIOS-e820: [mem 0x00000000bdcdc000-0x00000000bfffffff] reserved
  BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
  BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
  BIOS-e820: [mem 0x0000000100000000-0x00000001fbffffff] usable
  BIOS-e820: [mem 0x00000001fc000000-0x00000001ffffffff] reserved
  BIOS-e820: [mem 0x0000000200000000-0x000000023fffffff] usable

but as mentioned, there's bound to be some particular kernel layout
that triggers this, because I definitely ran a few kernels with that
commit in it without problems (and clearly other people are too).
Looking at my boot log, I had successful boots with both 6a57d104c8cb
and c2714334b944, which contains that commit.

It might also be that it causes some massive corruption at boot time,
but it then requires that that particular memory is actually used. So
maybe it's not so much about the memory map except indirectly.

But that commit *does* look a lot more likely than the things I looked at.

Markus, how did you happen to pinpoint that particular commit? Is it
entirely repeatable for you?

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/