linux-kernel - Re: [patch 0/4] x86: PAT followup - Incremental changes and bug fixes

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]

Date:	Thu, 17 Jan 2008 22:22:14 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andreas Herrmann3 <andreas.herrmann3@....com>
Cc:	Venki Pallipadi <venkatesh.pallipadi@...el.com>, ak@....de,
	ebiederm@...ssion.com, rdreier@...co.com,
	torvalds@...ux-foundation.org, gregkh@...e.de, airlied@...net.ie,
	davej@...hat.com, tglx@...utronix.de, hpa@...or.com,
	akpm@...ux-foundation.org, arjan@...radead.org,
	jesse.barnes@...el.com, davem@...emloft.net,
	linux-kernel@...r.kernel.org, suresh.b.siddha@...el.com
Subject: Re: [patch 0/4] x86: PAT followup - Incremental changes and bug
	fixes

* Ingo Molnar <mingo@...e.hu> wrote:

> * Andreas Herrmann3 <andreas.herrmann3@....com> wrote:
> 
> > Yes.
> > 
> > Meanwhile I have figured out that it is some ACPI stuff that maps the 
> > page cached. I've changed the ioremap's in drivers/acpi/osl.c to 
> > ioremap_nocache. See attached patch.
> > 
> > Now the machine boots without conflicts.
> 
> ah, nice!
> 
> but in general we must be robust enough in this case and just degrade 
> any overlapping page to UC (and emit a warning perhaps) - instead of 
> failing the ioremap and thus failing the driver (and the bootup).

btw., there's a change i did in today's x86.git: _all_ the old BIOS data 
accesses now go through early_ioremap(). This cleaned up the boot code 
quite significantly, as it's much more apparent now when we access a 
BIOS data table. (it also solves the problem when BIOS data pages are in 
reserved areas that we map via UC or dont map at all)

the same happens with all ISA ioremaps as well - no more "low 1MB is 
treated special" exceptions.

[ This also solves the 'EFI puts data pages into really high memory we
  dont have mapped yet' category of problems that BIOS writers are
  apparently busy creating right now ;-) ]

the downside is that old linear-mapped assumptions might now result in 
an early fault - boot with earlyprintk=vga or 
earlyprintk=serial,ttyS0,115200. I fixed most such assumptions already 
and booted an allyesconfig kernel on both 32-bit and 64-bit x86, but a 
few more remain still. I've enhanced the early fault printout code as 
well to make it easier to debug such things, so it should be relatively 
easy to find the rest.

	Ingo
--
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/