From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Tue, 16 Oct 2012 08:31:20 +0200
Subject: [U-Boot] [PATCH] Prevent malloc with size 0
In-Reply-To: <4F7AD261.60304@gmail.com>
References: <4CC006B1.8000905@intracomdefense.com>
	<CALButCKSyhmfwKfqfyMw03hRRmDRvrz7qisni5DvkyiAz+TiOg@mail.gmail.com>
	<4F7AD261.60304@gmail.com>
Message-ID: <201210160831.20759.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Graeme Russ,

> On 04/03/2012 09:35 AM, Graeme Russ wrote:
> > Hi Jocke
> > 
> > And I really need to check, but I have a sneaking suspicion that as the
> > code currently stands in U-Boot/x86 dereferencing a NULL pointer won't
> > cause an exception. In x86, U-Boot configures all protected mode segments
> > to be 4GB starting at physical address 0x00000000 with no virtual address
> > translation. Accessing physical address 0x00000000 is just as valid as
> > accessing 0x00000001 (or any other address).
> > 
> > Now if I set segments to start at 0x00000002 then I can trap a
> > segmentation fault for accesses to 0x00000000 (NULL) and 0x00000001
> > (malloc(0) pointer)
> > 
> > That will mean that U-Boot cannot ever access those two bytes of memory,
> > but I doubt that I would ever want to. And I will need to set the
> > segments to base address 0x00000000 before jumping into Linux...
> 
> OK, this is not as easy as it sounds. Detecting NULL pointer dereferences
> will involve enabling paging[1] which is something I really do not want to
> do in U-Boot. Flat Protected Mode with a 4GB linear map is perfectly fit
> for purpose, and that is how the Linux kernel expects things to be
> configured so it will be a major PITA to change.
> 
> In short, returning non-NULL from malloc(0) and expecting a CPU exception
> when it is de-referenced is not going to fly.
> 
> If we choose this path, at least put a debug() statement in to warn when
> malloc(0) is called.
> 
> Regards,
> 
> Graeme
> 
> [1] Apparently the way do do it is to reserve the entire first 4kB page and
> mark it as 'not-present' so any access causes a page-fault.

Ok, I don't mean to reopen this can of worms again ... but what're we going to 
do about this patch?

Best regards,
Marek Vasut