From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8307 invoked by alias); 20 Jun 2011 14:43:42 -0000 Received: (qmail 8278 invoked by uid 22791); 20 Jun 2011 14:43:42 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qy0-f175.google.com (HELO mail-qy0-f175.google.com) (209.85.216.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Jun 2011 14:43:27 +0000 Received: by qyk30 with SMTP id 30so1451049qyk.20 for ; Mon, 20 Jun 2011 07:43:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.17.148 with SMTP id s20mr4060385qca.149.1308581006874; Mon, 20 Jun 2011 07:43:26 -0700 (PDT) Received: by 10.229.47.78 with HTTP; Mon, 20 Jun 2011 07:43:26 -0700 (PDT) In-Reply-To: <4DFF5A40.8000903@zytor.com> References: <20110620135115.GA11874@lucon.org> <4DFF50E0.8030404@codesourcery.com> <4DFF5A40.8000903@zytor.com> Date: Mon, 20 Jun 2011 14:46:00 -0000 Message-ID: Subject: Re: [x32] PATCH: Remove ix86_promote_function_mode From: "H.J. Lu" To: "H. Peter Anvin" Cc: Bernd Schmidt , gcc-patches@gcc.gnu.org, Eric Botcazou Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg01485.txt.bz2 On Mon, Jun 20, 2011 at 7:33 AM, H. Peter Anvin wrote: > 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. =A0Promoting *NON*-pointers (or rather, requiring non-pointers to > having already been zero extended) is a security concern. =A0I thought I'd > made that point clear already. =A0This is a hideously critical distinctio= n. I can promote pointers then. >> 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. > 32bit pointers are zero-extended to 64bit when passing in registers to kernel. --=20 H.J.