From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16952 invoked by alias); 21 Jun 2011 00:21:24 -0000 Received: (qmail 16938 invoked by uid 22791); 21 Jun 2011 00:21:24 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_OV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Jun 2011 00:21:07 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5L0KaO7031663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Jun 2011 20:20:36 -0400 Received: from pebble.twiddle.home (vpn-239-71.phx2.redhat.com [10.3.239.71]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5L0KZQh009732; Mon, 20 Jun 2011 20:20:35 -0400 Message-ID: <4DFFE3BF.9080605@redhat.com> Date: Tue, 21 Jun 2011 00:34:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Thunderbird/3.1.10 MIME-Version: 1.0 To: "H. Peter Anvin" CC: "H.J. Lu" , 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> <4DFF5A40.8000903@zytor.com> <4DFFCE63.3090209@redhat.com> <4DFFDA4C.5050603@zytor.com> In-Reply-To: <4DFFDA4C.5050603@zytor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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/msg01551.txt.bz2 On 06/20/2011 04:39 PM, H. Peter Anvin wrote: > sys_foo: > cmpl $10, %edi > jae .L1 > > movq foo_table(,%rdi,3), %rax > retq > .L1: > movq $-EINVAL, %rax > retq > > Enter this function with a non-normalized %rdi and you have a security > hole even though the C is perfectly fine. Yes, I get that. Isn't it already the case that x86_64 defines the upper half of 32-bit inputs as garbage? Assuming you're never intending to run an x32 kernel, but always an x32 environment within an x86_64 kernel, where does the talk of security holes wrt non-pointers come from? r~