linux-kernel - Re: [PATCH] x86: efi/e820 table merge fix

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:	Tue, 16 Jun 2009 21:03:32 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Huang Ying <ying.huang@...el.com>
CC:	Cliff Wickman <cpw@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"yinghai@...nel.org" <yinghai@...nel.org>
Subject: Re: [PATCH] x86: efi/e820 table merge fix

Huang Ying wrote:
>>> Why does BIOS mark memory region without EFI_MEMORY_WB as these types?
>>> Any example?
>>>
>> Probably not, but if it does, it's broken, and the memory should be
>> ignored. The original code had the EFI_MEMORY_WB check already, so it
>> seems prudent to keep it.
> 
> Maybe we need a real life example for that "fix". And attribute that to
> the vendor in comments.
> 
> Best Regards,
> Huang Ying

I think you're reading the patch backwards.

Before the patch, the EFI code didn't look at the type *AT ALL*, it only
looked at the EFI_MEMORY_WB attribute.  This broke for SGI when they
were -- correctly -- reserving real memory (and hence still
EFI_MEMORY_WB) with the type set to EFI_RESERVED_TYPE.  This is correct
behavior, but the old code saw that it was EFI_MEMORY_WB and therefore
considered it usable RAM.  This is obviously broken.

Now why, you're asking, do we still look at md->attribute at all?
That's where caution dictates that it is prudent to diverge from the
previous behavior, but it is not *this* patch that should be the source
of that question, but from the author of the existing code, which
appears to be Paul Jackson of SGI.  Unfortunately, his email now bounces
and noone has that information.

If you think about it, though, we don't want to consider it as usable
RAM if it isn't EFI_MEMORY_WB, and it would in fact be a bug (or
workaround for a broken system) to ignore it.  In fact, we go through
great pains elsewhere in the kernel to remove memory which isn't WB from
the usable pool.

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