From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754676AbcBZPaw (ORCPT ); Fri, 26 Feb 2016 10:30:52 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:28633 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754102AbcBZPav (ORCPT ); Fri, 26 Feb 2016 10:30:51 -0500 Subject: Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , Brian Gerst References: <1456413395-7679-1-git-send-email-boris.ostrovsky@oracle.com> <56D02EAA.4090200@citrix.com> <56D0587C.7080607@oracle.com> <56D06AD9.6090200@oracle.com> <56D06DA1.1050003@citrix.com> Cc: Konrad Rzeszutek Wilk , David Vrabel , andrew.cooper3@citrix.com, Linux Kernel Mailing List , mcgrof@kernel.org, xen-devel@lists.xenproject.org From: Boris Ostrovsky Message-ID: <56D06FAD.7060906@oracle.com> Date: Fri, 26 Feb 2016 10:30:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <56D06DA1.1050003@citrix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/26/2016 10:22 AM, Roger Pau Monné wrote: > El 26/2/16 a les 16:10, Boris Ostrovsky ha escrit: >> On 02/26/2016 09:42 AM, Brian Gerst wrote: >>> On Fri, Feb 26, 2016 at 8:51 AM, Boris Ostrovsky >>> wrote: >>>> On 02/26/2016 05:53 AM, Roger Pau Monné wrote: >>>>> El 25/2/16 a les 16:16, Boris Ostrovsky ha escrit: >>>>>> PV guests need to have their .bss zeroed out since it is not >>>>>> guaranteed >>>>>> to be cleared by Xen's domain builder >>>>> I guess I'm missing something, but elf_load_image (in libelf-loader.c) >>>>> seems to be able to clear segments (it will zero the memory between >>>>> p_paddr + p_filesz and p_paddr + p_memsz) while loading the ELF into >>>>> memory, so if the program headers are correctly setup the .bss >>>>> should be >>>>> zeroed out AFAICT. >>>> Right, but I don't think this is guaranteed. It's uninitialized data >>>> so in >>>> principle it can be anything. >>>> >>>> The ELF spec says "the system initializes the data with zero when the >>>> program begins to run" which I read as it's up to runtime and not the >>>> loader >>>> to do so. >>>> >>>> And since kernel does it explicitly on baremetal path I think it's a >>>> good >>>> idea for PV to do the same. >>> It does it on bare metal because bzImage is a raw binary image, not ELF. >> OK, I didn't think about this. >> >> But nevertheless, is it guaranteed that .bss is cleared by the loader? >> My reading of the spec is that it's not. > I think this is very blur in general. The copy of the spec I have says: > > "the system initializes the data with zeros when the program begins to run" > > What is "the system" here, Xen or the guest kernel? > > Just to be clear, I'm not opposing to this change in any way, but the > message in patch 1/2 needs to be fixed: > > "They have been able to run without problems because Xen domain builder > happens to give out zeroed pages." > > This is wrong IMHO, .bss is not cleared because we are using zeroed > pages, but because elf_load_image explicitly zeroes the space between > p_filesz and p_memsz in ELF program headers (which is were .bss resides > on properly arranged ELF binaries) when loading them. That's what I meant --- that the builder/loader gives out zeroed pages, not that Xen's allocator clears them in general. I'll update the commit message. > > I'm quite sure NetBSD also relies on this, so I would say it's > intrinsically part of the Xen boot ABI now, and this change just adds > seatbelts to Linux. Maybe NetBSD should drive carefully then ;-) -boris