From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13450 invoked by alias); 20 Jun 2011 14:34:32 -0000 Received: (qmail 13278 invoked by uid 22791); 20 Jun 2011 14:34:31 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from terminus.zytor.com (HELO mail.zytor.com) (198.137.202.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 14:34:12 +0000 Received: from tazenda.hos.anvin.org ([IPv6:2001:470:861f:0:e269:95ff:fe35:9f3c]) (authenticated bits=0) by mail.zytor.com (8.14.4/8.14.4) with ESMTP id p5KEXgUx030645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Jun 2011 07:33:43 -0700 Message-ID: <4DFF5A40.8000903@zytor.com> Date: Mon, 20 Jun 2011 14:41:00 -0000 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: "H.J. Lu" CC: Bernd Schmidt , gcc-patches@gcc.gnu.org, Eric Botcazou Subject: Re: [x32] PATCH: Remove ix86_promote_function_mode References: <20110620135115.GA11874@lucon.org> <4DFF50E0.8030404@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg01482.txt.bz2 On 06/20/2011 07:01 AM, H.J. Lu wrote: > On Mon, Jun 20, 2011 at 6:53 AM, Bernd Schmidt wrote: >> On 06/20/2011 03:51 PM, H.J. Lu wrote: >>> Promote pointers to Pmode when passing/returning in registers is >>> a security concern. No. Promoting *NON*-pointers (or rather, requiring non-pointers to having already been zero extended) is a security concern. I thought I'd made that point clear already. This is a hideously critical distinction. > Peter, do you think it is safe to assume upper 32bits are zero in > user space for x32? Kernel isn't a problem since pointer is 64bit > in kernel and we don't pass pointers on stack to kernel. As I have already stated, if we *cannot* require pointers to be zero-extended on entry to the kernel, we're going to have to have special entry points for all the x32 system calls except the ones that don't take pointers. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.