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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r4j92sez.fsf@xmission.com>
Date:	Wed, 20 Mar 2013 23:11:48 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
Cc:	vgoyal@...hat.com, cpw@....com, kumagai-atsushi@....nes.nec.co.jp,
	lisa.mitchell@...com, heiko.carstens@...ibm.com,
	akpm@...ux-foundation.org, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, zhangyanfei@...fujitsu.com
Subject: Re: [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to get position of program header table

HATAYAMA Daisuke <d.hatayama@...fujitsu.com> writes:

> From: "Eric W. Biederman" <ebiederm@...ssion.com>
> Subject: Re: [PATCH v3 01/21] vmcore: reference e_phoff member explicitly to get position of program header table
> Date: Tue, 19 Mar 2013 14:44:16 -0700
>
>> HATAYAMA Daisuke <d.hatayama@...fujitsu.com> writes:
>> 
>>> Currently, the code assumes that position of program header table is
>>> next to ELF header. But future change can break the assumption on
>>> kexec-tools and the 1st kernel. To avoid worst case, reference e_phoff
>>> member explicitly to get position of program header table in
>>> file-offset.
>> 
>> In principle this looks good.  However when I read this it looks like
>> you are going a little too far.
>> 
>> You are changing not only the reading of the supplied headers, but
>> you are changing the generation of the new new headers that describe
>> the data provided by /proc/vmcore.
>> 
>> I get lost in following this after you mangle merge_note_headers.
>> 
>> In principle removing silly assumptions seems reasonable, but I think
>> it is completely orthogonal to the task of maping vmcore mmapable.
>> 
>> I think it is fine to claim that the assumptions made here in vmcore are
>> part of the kexec on panic ABI at this point, which would generally make
>> this change unnecessary.
>
> This was suggested by Vivek. He prefers generic one.
>
> Vivek, do you agree to this? Or is it better to re-post this and other
> clean-up patches as another one separately to this patch set?

My deep problem with this patch was that you were changing how we think
about the generated headers, and that just didn't seem to make any
sense, and certainly it seems to be orthogonal from the patch itself.

For headers that we generate it is perfectly fine to make all kinds of
assumptions.

Eric

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