From owner-svn-src-head@freebsd.org Wed Mar 22 14:16:55 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE54DD17D67 for ; Wed, 22 Mar 2017 14:16:55 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99FA816ED for ; Wed, 22 Mar 2017 14:16:55 +0000 (UTC) (envelope-from ed@nuxi.nl) Received: by mail-yw0-x22e.google.com with SMTP id i203so14763597ywc.3 for ; Wed, 22 Mar 2017 07:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuxi-nl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iv5u99LrGqmFl6wVBoD0rN4RH1r9HJzGUSGa3Bk6Wls=; b=t4xmwDsY0GIV8+VnuOAHqIKv8aiNP4X2cq3RQ5hpWM2gLfsgupMWLwbJTc5z4p4P7Y xoUzdOUVJmq9doiESPmKRv81MpLPAP4GnEdRTsJzUbGVICovEDyRenYcHyM4iIF1YOUq AFHMHDeAIUZSxy2nkwheZZr24mKDqxLjL5iO9pdc++6iDUlhHgq8qEqHXN0PWm8aniZ4 VeL05bTXKW3on9xXZudQZfLaUHSXeYUdYSo5lBPLjBXjfR9EJh0HPn8hfWbmiSmIisMw ARiV3p0wg0t+JOfdEqfFhaSTuPGxsGE7V8+rJDDBSxHFcVqqLe4xrd+GvWLyYz2UoonA rbxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iv5u99LrGqmFl6wVBoD0rN4RH1r9HJzGUSGa3Bk6Wls=; b=tAHRmsJjjI/tghZ8U5pmgqOvhznS9ncety2Kq2I8YcL9acbdSZInkFjybgnrb/xQs+ ASkhix6oYXg6kGTUnrNWKje4AsJRZQWVEqrqjvJOVzobMGw/CTkM4kid7swVf33UFbcy 7hH+e8yfcr6+p0a9OvGEBHmcphagNyE9lmc70pquSGsJfo5xs7ulIiCiDqvPJIAOWFct u6Z7LR9hKR8u9qGZlTsUYbra82A3Hak2wQt2nBQlD4XSomTRgZiyUWaRxX+Jdls4dpif /tRAIxgsTiuJXJL+pixJ0Oewbov/g8U/f13meoAy+OfwnHVV9vC/9MKo44yYAaiEIEad kPcg== X-Gm-Message-State: AFeK/H1p6BBhyEYGCfjk/HDZV3MFL4/E1MqjoGPwgswRmtvKFWeysbTenIhdXtpmuLkUfHO6gEryMYJyWS2MVw== X-Received: by 10.37.65.7 with SMTP id o7mr26983283yba.70.1490192214533; Wed, 22 Mar 2017 07:16:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.51.198 with HTTP; Wed, 22 Mar 2017 07:16:24 -0700 (PDT) In-Reply-To: <20170322090258.GR43712@kib.kiev.ua> References: <201703220705.v2M75RHE066483@repo.freebsd.org> <20170322090258.GR43712@kib.kiev.ua> From: Ed Schouten Date: Wed, 22 Mar 2017 15:16:24 +0100 Message-ID: Subject: Re: svn commit: r315701 - in head/sys: amd64/cloudabi32 amd64/cloudabi64 arm/cloudabi32 arm64/cloudabi64 i386/cloudabi32 To: Konstantin Belousov Cc: Ed Schouten , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 14:16:56 -0000 Hi Kostik, 2017-03-22 10:02 GMT+01:00 Konstantin Belousov : > On Wed, Mar 22, 2017 at 07:05:27AM +0000, Ed Schouten wrote: >> Author: ed >> Date: Wed Mar 22 07:05:27 2017 >> New Revision: 315701 >> URL: https://svnweb.freebsd.org/changeset/base/315701 >> >> Log: >> Set the interpreter path to /nonexistent. >> >> CloudABI executables are statically linked and don't have an >> interpreter. Setting the interpreter path to NULL used to work >> previously, but r314851 introduced code that checks the string >> unconditionally. Running CloudABI executables now causes a null pointer >> dereference. > You could have just reported that the revision breaks cloudabi. Even though that revision made things crash for me, prior versions of imgact_elf.c also dereferenced interp_path in several places, which I interpreted as CloudABI not being a good citizen. >> Looking at the rest of imgact_elf.c, it seems various other codepaths >> already leaned on the fact that the interpreter path is set. Let's just >> go ahead and pick an obviously incorrect interpreter path to appease >> imgact_elf.c. > > I believe that we should move in the reverse direction, in particular, > best would be to allow brand to specify that only a statically linked > binaries can be handled by it. My reasoning is coming from a desire > to make brand matching as exact as possible, after dealing with the > bugs due to too vague matching. I agree. Sounds perfect! Similarly, I seem to remember CloudABI's brandinfos set compat_3_brand for a similar reason: it seems to be required by imgact_elf.c. Would we also want to change that? > Could you test the following ? It supposedly fixes the NULL issue, and > adds the flag marking brands as only allowing static (really PT_INTERP-less) > binaries. I've just given it a try. It works perfectly for me. Thanks! -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717