linux-kernel - Re: [PATCH v2] x86, efi: Do not reserve boot services regions within reserved areas

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: <1308073228.21026.20.camel@Joe-Laptop>
Date:	Tue, 14 Jun 2011 10:40:28 -0700
From:	Joe Perches <joe@...ches.com>
To:	Maarten Lankhorst <m.b.lankhorst@...il.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Yinghai Lu <yinghai@...nel.org>, Jim Bos <jim876@...all.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] x86, efi: Do not reserve boot services regions
 within reserved areas

On Tue, 2011-06-14 at 19:26 +0200, Maarten Lankhorst wrote:
> Op 14-06-11 19:05, Joe Perches schreef:
> > On Tue, 2011-06-14 at 18:19 +0200, Maarten Lankhorst wrote:
> >> Commit 916f676f8dc started reserving boot service code since some systems
> >> require you to keep that code around until SetVirtualAddressMap is called.
> > []
> >> Signed-off-by: Maarten Lankhorst <m.b.lankhorst@...il.com>
> > Hello Maarten, just trivia.
> >
> >> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> > []
> >> +			memblock_dbg(PFX "Could not reserve boot area "
> >> +				"[0x%llx-0x%llx)\n", start, start+size);
> > I believe this should be:
> >
> > 			memblock_dbg(PFX "Could not reserve boot area 0x%llx-0x%llx)\n",
> > 				     start, start + size - 1);
> Erm, no. [x...y) means the range of x to y without including y.
> 
> Other efi code followed that convention, and the e820 code does the same, silently.
> 
> [    0.000000] BIOS-provided physical RAM map:
> [    0.000000]  BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
> ...
> [    0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000008000) (0MB)
> 
> ~Maarten

The other memblock_dbg uses with range seem to disagree

$ grep -A1 -rP --include=*.[ch] "memblock_dbg.*\%.*llx" *
arch/x86/mm/memblock.c:		memblock_dbg("  [%010llx-%010llx]\n", (u64)r->base, (u64)r->base + r->size - 1);
arch/x86/mm/memblock.c-		final_start = PFN_DOWN(r->base);
--
arch/x86/mm/memblock.c:	memblock_dbg("    memblock_x86_reserve_range: [%#010llx-%#010llx] %16s\n", start, end - 1, name);
arch/x86/mm/memblock.c-
--
arch/x86/mm/memblock.c:	memblock_dbg("       memblock_x86_free_range: [%#010llx-%#010llx]\n", start, end - 1);
arch/x86/mm/memblock.c-
--
mm/memblock.c:	memblock_dbg("memblock: %s array is doubled to %ld at [%#010llx-%#010llx]",
mm/memblock.c-		 memblock_type_name(type), type->max * 2, (u64)addr, (u64)addr + new_size - 1);



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