From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5268 invoked by alias); 20 Jun 2011 23:40:47 -0000 Received: (qmail 5253 invoked by uid 22791); 20 Jun 2011 23:40:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_OV,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 23:40:23 +0000 Received: from anacreon.sc.intel.com (hpa@localhost [127.0.0.1]) (authenticated bits=0) by mail.zytor.com (8.14.4/8.14.4) with ESMTP id p5KNduhP008493 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 20 Jun 2011 16:39:57 -0700 Message-ID: <4DFFDA4C.5050603@zytor.com> Date: Tue, 21 Jun 2011 00:33: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: Richard Henderson 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> In-Reply-To: <4DFFCE63.3090209@redhat.com> 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/msg01550.txt.bz2 On 06/20/2011 03:49 PM, Richard Henderson wrote: >> >> 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. > > If it's a security concern, surely you have to do it in the kernel > anyway, lest someone call into the kernel via their own assembly > rather than something controlled by the compiler... > That was the point... right now we rely on the ABI to not have any invalid representations (except, as far as I know, on s390). This means any arbitrary register image presented to the kernel will be a set of valid C objects; we then accept or reject them as being semantically valid using normal C code in the kernel. The issue occurs when the kernel can be entered with something in the register that is invalid according to the calling convention, and not have it rejected. The current x86-64 ABI rules, for example, imply that if %rdi = 0x3fb8c9119537d37d and the type of the first argument is uint32_t, that is a valid argument with the value 0x9537d37d. The extra upper bits are ignored, and so no security issue arises. The issue with requiring the upper bits to be normalized occurs with code like: static const long foo_table[10] = { ... }; long sys_foo(unsigned int bar) { if (bar >= 10) return -EINVAL; return foo_table[bar]; } If the upper bits are required to be zero, gcc could validly translate that to: 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. -hpa