From nobody Fri May 16 14:11:12 2025 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZzTX44hWSz5vmwn for ; Fri, 16 May 2025 14:11:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZzTX42hkwz486l; Fri, 16 May 2025 14:11:16 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-6f6e398767eso42381986d6.1; Fri, 16 May 2025 07:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1747404675; x=1748009475; darn=freebsd.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=XpoA+xgd8fEpKvHQ5aZbHuyg21JF29cNfUdLU9ign/Y=; b=mvf++ST4UuSVPfy7mLiV/PGoYiA2/t2twdm22X1cvyKR5fB03ohM4QyA4yru9wvI1N sLwNO/WUlqLjpOOyqH0bBaayt1p0VJo0SQJTLMfROl+IzVB+xJx9pXBAOUDW8il2nIxc OgIqHvaM26tgAMx6mXx60Yj0F6TEiEqjNBu3AaW16LrUDPrbpsBxRg6OBba05T46f1P6 V1FVu/VEjbneO2Jli6doW7ltiJoltvDqID3JpRQmX573qskWf3hQKS5Q6lEyE56j1FE3 c6RyYRx6qsUfBBE1BWskSAINe7xG95i9aSufJKhzeqK/L1DeULqDPP9VL7ca1xS1hYuo oIjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747404675; x=1748009475; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XpoA+xgd8fEpKvHQ5aZbHuyg21JF29cNfUdLU9ign/Y=; b=d9xbhqrE9+YFUQ3yLeq8h5ajMqe6EreFASUn3GEi8Pfi3ClZcx2d03V1WTyOC9laGi 7JqZ+KBMkoySVAgUvskJGdQ9PcsXHdwYgGruvSfhsVvDzYKg6ON5OkGGT9agcZfE21vR S6a3Y7Pc/Jt0Wk/HIxIyZ8bOjmPLQR47iLp3dz4d1Znuy3Tmz/VM7C1pnR42GXd/84b6 Vnj5azjHRzYwrccL43mt28ZRL//2Rk4zMTgF3zO0mmS6gzqEWyJBltev1WbmbzynQLaA WQb+pD7M6KU/y6HcT+SBm/zJ1cwLlsIyINWCe4YcMIqXExA1q5lqXCa0vPeBSjTh6tT+ vy1Q== X-Forwarded-Encrypted: i=1; AJvYcCW9pYOgVrolbJ73SUdkDaBMxxOJRr50GRDWgTux2hIMIBgDAkerb68c8gxusEkMP5/qwP7hRxfx@freebsd.org X-Gm-Message-State: AOJu0YyTF5MD0sIUbuelgYNb0OOHz2feZ/eSsamBh4FANjspXqvVY3CU EbPWZ9OTNHjAJ7jJDfMA6KDZlsa8MJmMPobdBZdinrEERog5MmIYBt9YK1DOf3yL X-Gm-Gg: ASbGnctC5WdcR+4B7702ST/J8HR4REGFOatlSETAHRSGHWKwjAFRB8Gf7ppf+Wf9Rze WCoklik0CsFNH8QExO2+tooR/lNEQS43wdf8YlRQ1BbKqTFyJNJYRGh6bt9U0JZCxF5xpsD36HQ FizqD11EkQqeHiKHIbhFmdfANw+oXjTLYIYlFtOC/R3RR/UUhjgKdK7lLd3oZvf6hYNp6LJn4Vi 9bu2FiqiHA9gSGWasCiOvsAfB+j20XVNfFPRFy2c74voreMIZ7QqJ7ns6JJCt1yanaEDGSYSZEp IKxVG8tnQRWJEn9blpA8W7gqePGMj96srd4GvwmCz1O0XQUkS/cddjlJ96BeKkrwkg== X-Google-Smtp-Source: AGHT+IG1GLBmCvvFEJhUxlsFDxTbl+NUrecUVp1Xqol1lrNYiZiuCH2xL1zjRq4BenguEQm3BhYEMA== X-Received: by 2002:a05:6214:20ab:b0:6f4:f157:40ad with SMTP id 6a1803df08f44-6f8b123bf2dmr53250046d6.2.1747404674959; Fri, 16 May 2025 07:11:14 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6f8b08ac502sm12650576d6.42.2025.05.16.07.11.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 May 2025 07:11:14 -0700 (PDT) Date: Fri, 16 May 2025 10:11:12 -0400 From: Mark Johnston To: Andriy Gapon Cc: Konstantin Belousov , FreeBSD Current Subject: Re: RTLD_DEEPBIND question Message-ID: References: <900c8521-559a-47b5-acaa-ae941f6852c4@freebsd.org> <7c4e1682-d797-493c-8326-08d51dde3359@FreeBSD.org> <59db8ace-770f-4f73-976f-411f6de0885a@FreeBSD.org> <5b887290-a6aa-49ff-aa92-f335ed09b9a5@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b887290-a6aa-49ff-aa92-f335ed09b9a5@freebsd.org> X-Rspamd-Queue-Id: 4ZzTX42hkwz486l X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Spamd-Bar: ---- On Fri, May 16, 2025 at 03:22:52PM +0300, Andriy Gapon wrote: > On 27/04/2025 17:26, Mark Johnston wrote: > > On Thu, Apr 24, 2025 at 08:56:44AM +0300, Andriy Gapon wrote: > > > On 23/04/2025 21:56, Andriy Gapon wrote: > > > > BTW, I've been wondering how illumos avoids the problem even though they > > > > do not use any special dlopen flags. > > > > It turns out that they link almost all system shared libraries with > > > > -Bdirect option (which is Solaris/illumos specific). > > > > It's somewhat similar to, but different from, -Bsymbolic. > > > > https://docs.oracle.com/cd/E23824_01/html/819-0690/aehzq.html#scrolltoc > > > > https://docs.oracle.com/cd/E36784_01/html/E36857/gejfe.html > > > > > > Oh, and it looks like there is an even better explanation for illumos. > > > There is a version map file for libdtrace which explicitly lists API > > > functions and makes everything else local. > > > https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libdtrace/common/mapfile-vers > > > > > > I wonder why we didn't do the same when porting. > > > Maybe we should do that now? > > > > I don't have any objection, but I believe adding a version map after the > > fact doesn't accomplish much, assuming that we care deeply about ABI > > stability in libdtrace.so (I'm not sure we do though). > > My primary goal here is not ABI stability, but hiding symbols that really > should not be exported. See more at the end. > > At the same time I am not sure why it could be too late to start caring > about ABI stability now. Assuming we actually would want to do that. I just mean that the version map helps only helps provide stability for binaries linked to libdtrace.so after the version map is introduced. > And I don't want to single out libtrace here. > It seems that the story is the same for all libraries that have been ported > from illumos. > E.g., libzfs_core was supposed to be a library that cares greatly about its > API / ABI stability. > > > > > I think that on FreeBSD we should use symbol visibility attributes or a > > > > symbol map to hide (make local) symbols that are not expected to be > > > > interposed or have a high chance to be interposed by accident. > > > > > > > > IMO, yyparse should definitely get that treatment. > > > > > > > > I think that approach would be better than magic rtld tricks. > > > > Especially because the tricks do not work with the current rtld. > > > > I'd rather make a change to libdtrace.so than to rtld. > > > > > > This, while not as nice as the illumos solution, fixes my specific issue: > > > diff --git a/cddl/lib/libdtrace/Makefile b/cddl/lib/libdtrace/Makefile > > > index d086fffb07bc..58054d129b49 100644 > > > --- a/cddl/lib/libdtrace/Makefile > > > +++ b/cddl/lib/libdtrace/Makefile > > > @@ -146,7 +146,8 @@ CFLAGS+= -fsanitize=address -fsanitize=undefined > > > LDFLAGS+= -fsanitize=address -fsanitize=undefined > > > .endif > > > > > > -LIBADD= ctf elf proc pthread rtld_db xo > > > +VERSION_MAP= ${.CURDIR}/Symbol.map > > > +LIBADD= ctf elf proc pthread rtld_db xo > > > > > > CLEANFILES= dt_errtags.c dt_names.c > > > > > > diff --git a/cddl/lib/libdtrace/Symbol.map b/cddl/lib/libdtrace/Symbol.map > > > new file mode 100644 > > > index 000000000000..89ee9de65209 > > > --- /dev/null > > > +++ b/cddl/lib/libdtrace/Symbol.map > > > @@ -0,0 +1,4 @@ > > > +{ > > > + local: > > > + yy*; > > > +}; > > > > This just gives the lexer/parser symbols in libdtrace.so local > > visibility? I think that's fine. > Yes, that's the intention. > > I tested locally two versions of Symbol.map for libdtrace. > The basic one quoted here and a more extended one based on illumos > lib/libdtrace/common/mapfile-vers. > The latter version does not define any symbol versions, its purpose is only > to be a white-list of things to make public / global: > https://people.freebsd.org/~avg/libdtrace-Symbol.map Do we really want to export _dtrace_debug? > Comparing to illumos I only had to add 3 dtrace_oformat* symbols, > > Both versions worked equally well in my tests, but maybe I missed more of > FreeBSD extensions. > > Which one would be better to get into the tree? Having a full whitelist seems preferable to me. Did you test lockstat as well? I believe it and dtrace(8) are the only users of libdtrace.so in the base system.