linux-kernel - Re: [PATCH] x86: fix e820_update

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:	Fri, 13 Mar 2009 12:13:21 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jan Beulich <jbeulich@...ell.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: fix e820_update_range()


* Jan Beulich <jbeulich@...ell.com> wrote:

> >>> Yinghai Lu <yinghai@...nel.org> 13.03.09 05:35 >>>
> >
> >Impact: fix left range size on head.
> >
> >| commit 5c0e6f035df983210e4d22213aed624ced502d3d
> >|    x86: fix code paths used by update_mptable
> >|    Impact: fix crashes under Xen due to unrobust e820 code
> >fix one bug about e820 referring, but introduce other bug
> >
> >need update size for left range at first in case it is header.
> >
> >also add __e820_add_region take more parameter.
> >
> >Signed-off-by: Yinghai Lu <yinghai@...nel.org>
> >...
> >+		/*
> >+		 * left range could be head or tail, so need to update
> >+		 * size at first.
> >+		 */
> >+		ei->size -= final_end - final_start;
> > 		if (ei->addr < final_start)
> > 			continue;
> > 		ei->addr = final_end;
> >-		ei->size -= final_end - final_start;
> 
> The change of mine here was done on purpose, since I had 
> observed that in this particular case (when the changed region 
> starts later and ends earlier than the original region) 
> e820_add_region() would in any case create an overlapping 
> entry (which later gets cleaned up by sanitize_e820_map()). 
> That cleanup in sanitize_e820_map(), however, already implies 
> reducing the size of the enclosing region, and hence the 
> original code (and the code you try to restore now) 
> effectively shrinks the original region twice.
> 
> Consequently, the only alternative to the code as resulting 
> from my patch appears to be to avoid the generation of 
> overlapping entries in the first place, but that would clearly 
> make e820_update_range_map() more complex.

Still that looks like the best course of action - the core e820 
primitives should always produce a sane map.

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