From owner-svn-src-head@freebsd.org Sat May 30 23:47:40 2020 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AEFE82FB55B; Sat, 30 May 2020 23:47:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ZJ5R5PgHz3yD9; Sat, 30 May 2020 23:47:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-il1-f193.google.com with SMTP id a13so1265826ilh.3; Sat, 30 May 2020 16:47:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bXahRsOPlAZvmnTEiwGahR8U2PCBMMYgGy84EcVGcaM=; b=hGCb1LWyaHspsdnc7pvaQ0lTK7gcQWj6Cm8zDvcup0zgHKKB2SyD7w5jjM1Z4hwnTU QOcO/mFzDxBwV3W7npG6p5mLeI0m4zjMmxoDpcI2XSeaRf/4DPt1bnAR+j7W8ScugA8B aYfdCeyVKNuHboC1orVz1YYldI9P0NwdpGWnxyaXfWRrcl/fg4CkbwNm4+iOyaJuaXkV b5INgnt4rEzsw8+fZDRJslLbe0MGm8E1uIKInxingaQ3WuPtQtvd8uDDZmdb5X2GH3H+ ivdhukv6XGV+DZMF5j3BNExFOrkvMc0K2T0wAlJz4dPes5mOSd/o7gQnc1BtogclJ1OZ xmrg== X-Gm-Message-State: AOAM532C33rhb+C33m5DW4a5k3Jh9uMb59dzJHnWRtl1qT6DtlOWhY2E j7Qv97JTyePUjtAP/S1poVkJ3dUb97cQa4IPAJlTszb64T8= X-Google-Smtp-Source: ABdhPJy2eTEILoYZMIlRjAYVk0+6eN4UyO6pIhvPi8aqtxelr/UBhA87A4Z+9Ib6LgfQJQ8dKlHD8P8wDVVw8/FPxBw= X-Received: by 2002:a92:4a0d:: with SMTP id m13mr13732628ilf.98.1590882458661; Sat, 30 May 2020 16:47:38 -0700 (PDT) MIME-Version: 1.0 References: <202005301957.04UJvRkb020021@repo.freebsd.org> <20200530201405.GL48478@kib.kiev.ua> <20200530233928.GM48478@kib.kiev.ua> In-Reply-To: <20200530233928.GM48478@kib.kiev.ua> From: Ed Maste Date: Sat, 30 May 2020 19:47:26 -0400 Message-ID: Subject: Re: svn commit: r361657 - head/sys/sys To: Konstantin Belousov Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49ZJ5R5PgHz3yD9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.166.193 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-1.84 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.89)[-0.891]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.70)[-0.704]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.25)[-0.246]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.193:from]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.193:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 30 May 2020 23:47:40 -0000 On Sat, 30 May 2020 at 19:39, Konstantin Belousov wrote: > > > It looks like GNU ld has done it since 2015 in fact. Further, glibc > > will refuse to dlopen() an object with DF_1_PIE set, as of last June; > > this seems like it would be a reasonable thing for us to do too. > > > > glibc bug for this: https://sourceware.org/bugzilla/show_bug.cgi?id=24323 > > I can do it. What if such object is referenced by DT_NEEDED ? Hmm, good question. glibc has the following comment where they disallow it: > + /* dlopen of an executable is not valid because it is not possible > + to perform proper relocations, handle static TLS, or run the > + ELF constructors. For PIE, the check needs the dynamic > + section, so there is another check below. */ I would suggest that if it's the case we cannot correctly dlopen or handle a DT_NEEDED executable then we ought to fail.