linux-kernel - Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix CONFIG_X86

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4F45B35D.1010702@zytor.com>
Date:	Wed, 22 Feb 2012 19:32:45 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	mingo@...hat.com, mjg@...hat.com, linux-kernel@...r.kernel.org,
	keithp@...thp.com, rui.zhang@...el.com,
	huang.ying.caritas@...il.com, stable@...r.kernel.org,
	matt.fleming@...el.com, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, efi: Delete efi_ioremap() and fix CONFIG_X86_32
 oops

On 02/22/2012 06:20 PM, Yinghai Lu wrote:
> 
> Why is MAXMEM used here?
> 
> EFI reserved area could be above 4G?
> 
> if that is the case, you will map all mmio hole below 4g.
> 

OK, dropping this patch for now, at least from -urgent.

We really need to restrict the memory types we map, at least without
ioremap() called on them.  In theory, on x86-64, we could have a
dedicated "1:1" address for each physical address, but there is no good
reason we should ever map memory types other than RAM, ACPI and EFI by
default -- with the possible exception of the low 1 MiB legacy area.

Therefore, I don't see why on Earth we have
kernel_physical_mapping_init() create mappings for areas which are not
RAM.  It has access to the memory map at this point, so there is no
reason for it.  Unfortunately I think we still have a bunch of code
which implicitly assumes the old "PC" model with separate contiguous
memory ranges starting at 0, 1 MiB, and 4 GiB, however, there are more
and more systems where that just doesn't match reality.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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