From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id AEA9C3858D39 for ; Tue, 7 Mar 2023 13:08:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AEA9C3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x234.google.com with SMTP id s41so9503529oiw.13 for ; Tue, 07 Mar 2023 05:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678194482; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=02fvJh2qc+4SFaY7Q1ttu+hr66IdoeZxycDeY8o37TA=; b=u+Iz/nfaJBYl3pl13mlghmEgyzty+XgufZ0qkJyfztZl8L46sDHJY1aBwEcGq6s2TS 74QN/PkE97Xn7WNviLu45KRS7Qu5SOAPo0p7/buB1y3g2MmQKGIkwiap+ED3z+IYXSJv 9noG/aAd/U3GnWaKAdk4lfzcwKOeuBWCQbUV5O9dvaP3GBDXQPH66v6hiQO2trITSrrs sbNRX0fv7jBNVgNo8XCxydiZoivCRZjavqKcl7FTimdW01TPtcT5gyI9kWBJKhQOLInR R+c7lZFpr+Ndf5OTUAqQpVG0iulpCRtYMFJ3mjr8+E07W33QRE9XeKKDbEnVKs6zAIq1 /Zig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678194482; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=02fvJh2qc+4SFaY7Q1ttu+hr66IdoeZxycDeY8o37TA=; b=3Nn6lfNqFcJTXy7z+F/V7qkhgEDO1QRWsHhTjhYYW6jaD/CXfB0Ku7sI3Y9w8wkrAO AOkGooQJyGOtW9OMNA6lRnnZbbFhuxwTHUg/YlyJkXT3XhVjOCIV+yO3GO/xP/ZXnwNz Hj6j6JkiZRuMZIdJJkSN9nqG5JjiVDsuZv4Ek2+NpAwd4QRFknK5wSHBpeEqygGwRBrv N8eCf6XOcCYx4eWnAW0zD/kgTNvdWd6Dw2Rqqn2Mx6nVI/fOzns/zkajk7qkwScwrnGj XuV6DDtrrSZwkNaaFAFp45974IKsrKqJVG9zdqNQIMfn/XBrJOb4skx3DemFn7IXjfWE FovQ== X-Gm-Message-State: AO0yUKVc1GriDmdU1Wn2sVFGWwrA6mBv0tCC12UJhKNAt65LcrqhcdyK 4o6i5sPdQLYqk4F1dQ77y3JCUA== X-Google-Smtp-Source: AK7set9CyqCOTPOc7ZJuI8YyELO2JWfNEDHNf5FrgMHVcDxkyx3xDBSRjW6cq824zGwR0RMvgts8ZQ== X-Received: by 2002:a05:6808:313:b0:384:dffe:ef1c with SMTP id i19-20020a056808031300b00384dffeef1cmr240174oie.15.1678194481852; Tue, 07 Mar 2023 05:08:01 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c3:d849:85a1:d2e8:5a25:72e7? ([2804:1b3:a7c3:d849:85a1:d2e8:5a25:72e7]) by smtp.gmail.com with ESMTPSA id 5-20020aca1005000000b00383efcce195sm5086276oiq.8.2023.03.07.05.07.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Mar 2023 05:08:01 -0800 (PST) Message-ID: <2659aadc-6518-cc0e-d103-84eafcbdc3f9@linaro.org> Date: Tue, 7 Mar 2023 10:07:58 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs Content-Language: en-US To: Florian Weimer , Jan Kratochvil via Libc-alpha Cc: Jan Kratochvil , Anton Kozlov References: <87v8jdq7ht.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <87v8jdq7ht.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 07/03/23 05:40, Florian Weimer via Libc-alpha wrote: > * Jan Kratochvil via Libc-alpha: > >> Some projects snapshot+restore process images to migrate them to >> a different machine. The target machine may have different (particularly >> lower) set of CPU features. Restored process does crash in glibc IFUNC >> functions which have been already set in PLTs due to the former more >> rich CPU features on the snapshotting machine. >> >> Providing a glibc function which can be called during the restore. >> >> I understand the code may need more adjustments before its upstreaming >> but is this an acceptable approach? > > Do you have a high-level overview how this is supposed to work? Is CRIU > expected to call the new _dl_reset_ifunc symbol after restore? > > Use of is somewhat rare. Not even GCC uses it > AFAIK. It has its own cached CPU data used for target clones and > similar features. Re-running those IFUNC resolvers will just give the > same results. I am not sure if the ifunc reset will be really safe without adding CRIU migrate sync points, to avoid suspend execution in a context that the ifunc variants are already being executed or its address is being in a function point (for instance in PLT code). Besides, I also not sure if adding way to remove RELRO protection won't add more security issues (we can disable for sesuid binaries, but even though it is not a good security practice). > > Distributions have started to deploy alternate builds in > glibc-hwcaps/x86-64-v3 directories: > > openSUSE Tumbleweed gains optional x86-64-v3 optimization > > > This might be a common situation fairly soon. This is not IFUNC-based > at all, so any IFUNC-based approach is not going to help with that. > > Practically speaking, I think cluster heterogeneity needs to be hidden > at the cluster level. For glibc standpoint I think heterogeneity should be handled by masking off the higher cpu features sets so the programs always run with the lowest ifunc variants set.