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

Ingo Molnar wrote:
> * 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.
> 
yesterday i sent out
[PATCH] x86: make e820_update_range to handle small range update

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ