From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id 7E9EE3858C66 for ; Mon, 6 Mar 2023 13:43:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7E9EE3858C66 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-ot1-x32c.google.com with SMTP id g6-20020a056830308600b0068d4b30536aso5304514ots.9 for ; Mon, 06 Mar 2023 05:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678110218; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=M/8KCldVr/9bLrJutyCYeydqDCHx0FZn0F7E/G+I12E=; b=QUczqXECxWQ7g1ZKXPBvgkfkjdkLCUvCcZbmUlj7eeqvKebPU4sqHbBNNzKMirAVqy JoRIaTL4vm3xAe4C0RIfXGufFU9msbCsM2IpG3uybnaSuzrWbzVHFVAmH0ZwXlWkXqT2 T3fywDmDcp1ffMeebE4jGixDhSu+IgZ8CZkQa5OpWQ0/cQGfhiWESZnMM2VaXoN5Oo+J bPPq6IiKeDjpZpOCN/gZg5wu7CAuWjmEPxls33iG8/vbENGhCIUDaeeyWTeabAiBXXm/ sXP6wl1h1/vNGSAx89jLykUeGmdMDzAHZi6hRpHbbxyGDWJ5+1StfOnJWkyrcozbEIvD SS4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678110218; h=content-transfer-encoding:in-reply-to:organization:from:references :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=M/8KCldVr/9bLrJutyCYeydqDCHx0FZn0F7E/G+I12E=; b=AbzA0oobG5RGg5zBK03sElxpA/SMQsyFegzdBFiPxtp9rs7Y9aF+kszCXTm9A9Pv8V Ds2S4O7qMhweIlU8R2koBGR0wIK880oQFXqbdbbX5aQl3f9t+PvL66FpCjxdf6yshjO6 lAUuqb6wWMZc3o6/BwBggiX2hI8WO9voUFWMiyRlqlxgm5m97jO06CyXeORc8sg3iu/O lCFKWueaZPC1fKdHaWgTyd1e1b15TRjwWSlBdjqDjttJmlXkH/jo22tQxpPwvfVjqRHM GXrElsHb3tpGpMS6JiPOrr9dmj25h4eeBM7ybyqf7XXA1vuElJV8hf9cc2s08XIPfVnH q5eA== X-Gm-Message-State: AO0yUKUqmJoM2Ot19Ba+MvK3dNUBQ54T0kqg7IY47uuyC1D5cxXxHRcS B5rJwG29WTVRGtakR3wCfvCNEQ== X-Google-Smtp-Source: AK7set+uLJovl6wLWI2djdWrebBkMjafXXI/d1YR88zNXK5YWiuI9DcMW7KLn7RgLGMhxKkncok5/Q== X-Received: by 2002:a9d:410f:0:b0:68c:9eb:aaed with SMTP id o15-20020a9d410f000000b0068c09ebaaedmr5278347ote.32.1678110217648; Mon, 06 Mar 2023 05:43:37 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c3:d849:1545:df7d:92dc:75c9? ([2804:1b3:a7c3:d849:1545:df7d:92dc:75c9]) by smtp.gmail.com with ESMTPSA id o12-20020a9d718c000000b00693d8a315eesm4144242otj.31.2023.03.06.05.43.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Mar 2023 05:43:36 -0800 (PST) Message-ID: <558d7aa8-85cb-72a1-1d84-184ecb8d5328@linaro.org> Date: Mon, 6 Mar 2023 10:43:34 -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 v3 2/4] libio: Remove the usage of __libc_IO_vtables Content-Language: en-US To: Carlos O'Donell , libc-alpha@sourceware.org, Florian Weimer References: <20221227211145.3765256-1-adhemerval.zanella@linaro.org> <20221227211145.3765256-3-adhemerval.zanella@linaro.org> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 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 04/03/23 14:37, Carlos O'Donell wrote: > On 12/27/22 16:11, Adhemerval Zanella via Libc-alpha wrote: >> Instead of using a special ELF section along with a linker script >> directive to put the IO vtables within the RELRO section, the libio >> vtables are iall moved to an array marked as data.relro (so linker > > s/iall/all/g > >> will place in the RELRO segment without the need of extra directives). >> >> To avoid static linking namespace issues and to pulling all vtables > > s/to pulling/including/g > s/vtables/vtable/g > >> referenced objects, all required function pointers are set to weak alias. >> > > Have you tested this against legacy applications that interpose the vtables? > > In the original design Florian wrote: > ~~~ > To enable backwards compatibility, a special flag variable > (_IO_accept_foreign_vtables), protected by the pointer guard, avoids > process termination if libio stream object constructor functions have > been called earlier. Such constructor functions are called by the GCC > 2.95 libstdc++ library, and this mechanism ensures compatibility with > old binaries. Existing callers inside glibc of these functions are > adjusted to call the original functions, not the wrappers which enable > vtable compatiblity. > > The compatibility mechanism is used to enable passing FILE * objects > across a static dlopen boundary, too. > ~~~ I have not, but we do have tests for these (which was added after the vtable hardening with 29055464a03c72762969a2e8734d0d05d4d70e58). My understanding is it should cover the required interface for old binaries.