linux-kernel - Re: [tip:x86/urgent] x86: Make 64-bit efi

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: <19063.37940.634.400042@cargo.ozlabs.ibm.com>
Date:	Tue, 4 Aug 2009 11:51:47 +1000
From:	Paul Mackerras <paulus@...ba.org>
To:	Huang Ying <ying.huang@...el.com>
Cc:	"mingo@...hat.com" <mingo@...hat.com>,
	"hpa@...or.com" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/urgent] x86: Make 64-bit efi_ioremap use ioremap on
 MMIO regions

Huang Ying writes:

> This patch does not really fix the issue. __cpa_process_fault will warn
> if target memory area is beyond max_pfn_mapped. EFI runtime RAM area
> beyond max_pfn_mapped will trigger the warning too.

I think we already have that situation on that MacBook, and there is
no warning.  From dmesg:

[    0.000000] EFI: mem190: type=9, attr=0xf, range=[0x000000007fedf000-0x000000007feef000) (0MB)
[    0.000000] EFI: mem191: type=7, attr=0xf, range=[0x000000007feef000-0x000000007fef9000) (0MB)
[    0.000000] EFI: mem192: type=0, attr=0xf, range=[0x000000007fef9000-0x000000007feff000) (0MB)
[    0.000000] EFI: mem193: type=6, attr=0x800000000000000f, range=[0x000000007feff000-0x000000007ff00000) (0MB)
...
[    0.000000] last_pfn = 0x7fef9 max_arch_pfn = 0x400000000
...
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] init_memory_mapping: 0000000000000000-000000007fef9000
[    0.000000]  0000000000 - 007fe00000 page 2M
[    0.000000]  007fe00000 - 007fef9000 page 4k
[    0.000000] kernel direct mapping tables up to 7fef9000 @ 8000-c000
...
[    0.001920] init_memory_mapping: 000000007feff000-000000007ff00000
[    0.001926]  007feff000 - 007ff00000 page 4k

So the initial mapping ends at 0x7fef9000, and I believe that
max_pfn_mapped is 0x7fef9, and then EFI asks for pfn 0x7feff to be
mapped.  But I freely admit this is not my area of expertise.  This
machine has 2GB of RAM, by the way.

> To fix the issue. I think we can loose the restriction of
> __cpa_process_fault a little. Add a global variable max_pfn, which is
> max pfn of all memory type (including RAM, RESERVED, etc, mapped or
> unmapped), and __cpa_process_fault warns for memory area beyond max_pfn
> only.

It seemed cleaner to me to use ioremap() on areas that we are told are
MMIO.  Why would it be better to use init_memory_mapping for those
areas?

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