From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76888 invoked by alias); 22 Dec 2015 17:03:54 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 76865 invoked by uid 89); 22 Dec 2015 17:03:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=malicious, H*RU:!192.168.0.102!, H*r:ip*192.168.0.102, Hx-spam-relays-external:!192.168.0.102! X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 22 Dec 2015 17:03:51 +0000 Received: by mail-wm0-f67.google.com with SMTP id p187so22618201wmp.2 for ; Tue, 22 Dec 2015 09:03:51 -0800 (PST) X-Received: by 10.28.65.85 with SMTP id o82mr1902445wma.23.1450803828893; Tue, 22 Dec 2015 09:03:48 -0800 (PST) Received: from [192.168.0.102] (91.141.2.230.wireless.dyn.drei.com. [91.141.2.230]) by smtp.googlemail.com with ESMTPSA id w124sm25710975wmg.17.2015.12.22.09.03.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Dec 2015 09:03:47 -0800 (PST) Subject: Re: s390x ffi_closure_helper_SYSV References: <20151221183930.372366414@oc7340732750.ibm.com> From: Richard Plangger X-Enigmail-Draft-Status: N1110 Cc: Ulrich Weigand To: libffi-discuss@sourceware.org Message-ID: <56798272.706@gmail.com> Date: Tue, 22 Dec 2015 17:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151221183930.372366414@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015/txt/msg00115.txt.bz2 Hi, >> The program pollutes a fairly large junk of memory below the frame >> pointer and then calls back to a python function (from c). >> Because the ret_buffer variable (in ffi_closure_helper_SYSV) is not >> initialized properly, the returned value is not the same on s390x as it >> is on e.g. x86. > > The point is that if the user-callback were to fill in a full ffi_arg, > then ret_buffer would be completely filled. If ret_buffer isn't fully > written, then that's a bug in the callback PyPy provides to libffi. Because the return value (on s390x) contains contents from the stack, it looked malicious to me. >> `make` on my laptop (x86) returns without asserting, but >> it does not on s390x. PPC was recently implemented on PyPy and there we >> did also not hit this issue. > > Is this on little-endian or big-endian PowerPC? PyPy implements both. Cheers, Richard