From: Joe Buck <jbuck@synopsys.COM>
Message-Id: <200201031545.HAA14668@atrus.synopsys.com>
Subject: Re: [PATCH] C undefined behavior fix
To: paulus@samba.org
Date: Thu, 3 Jan 2002 07:45:24 -0800 (PST)
Cc: jbuck@synopsys.COM (Joe Buck), dewar@gnat.com, velco@fadata.bg,
        gcc@gcc.gnu.org, linux-kernel@vger.kernel.org,
        linuxppc-dev@lists.linuxppc.org, trini@kernel.crashing.org
In-Reply-To: <15411.52243.87016.442521@argo.ozlabs.ibm.com> from "Paul Mackerras" at Jan 03, 2002 02:12:19 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

> > There is already such a project under development: see
> > 
> > http://gcc.gnu.org/projects/bp/main.html
> > 
> > This is a modification to gcc that implements pointers as triples.
> > While there is a performance penalty for doing this, it can completely
> > eliminate the problem of exploitable buffer overflows.  However, programs
> > that violate the rules of ISO C by generating out-of-range pointers will
> > fail.
> 
> What will it do if I cast a pointer to unsigned long?  Or if I cast an
> unsigned long to a pointer?  The kernel does both of these things, and
> in a lot of places.

Perhaps you need to reread a book like K&R, second edition, to find out
what the C language promises you and what it doesn't.

The bounded-pointer approach represents a C pointer as three machine
pointers.  When you cast to unsigned long, it converts the "value"
pointer.  When you cast an unsigned long to a pointer, you lose the range
information, so the pointer's extent is anywhere in memory.  However,
if the compiler can determine by dataflow analysis where this value
came from it is entitled to put the original range information back.

> Part of my beef with what gcc-3 is doing is that I take a pointer,
> cast it to unsigned long, do something to it, cast it back to a
> pointer, and gcc _still_ thinks it's knows what I am doing.  It
> doesn't.

The C language standard defines quite precisely what the compiler is
allowed to assume and what it is not allowed to assume.  If you don't
like these rules, you will dislike *all* modern C compilers, especially
the expensive proprietary C compilers hardware vendors often use to
get good SPEC results.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/