linux-kernel - Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests

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]

Message-ID: <56D06DA1.1050003@citrix.com>
Date:	Fri, 26 Feb 2016 16:22:09 +0100
From:	Roger Pau Monné <roger.pau@...rix.com>
To:	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Brian Gerst <brgerst@...il.com>
CC:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	<andrew.cooper3@...rix.com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	<mcgrof@...nel.org>, <xen-devel@...ts.xenproject.org>
Subject: Re: [Xen-devel] [PATCH v3 0/2] Clear .bss for VP guests

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
>> <boris.ostrovsky@...cle.com> 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.

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.

Roger.