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
| ||
|
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/
Powered by blists - more mailing lists