From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 9FB813858D33 for ; Thu, 9 Mar 2023 15:47:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FB813858D33 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-x22b.google.com with SMTP id bp19so1974086oib.4 for ; Thu, 09 Mar 2023 07:47:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1678376874; 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=HxWSUXkz37nay0an/rvmgTRbsRs5nzwbi6ZLVuhcBk0=; b=DdAgCooIlUadaGrRRI+/ATXvUD8o8cu4eN8vxmEjEGIcozI+U29eFQjGS8AjZjZTG1 wqVD3R4Zq/p1YXiZWEJ5siwbPOjGKo0wg0D+qinZq5Z/boMp4LmqG2Z6tcXb+dehSH9H qUlmfYDSGpM8DSJ9cmXY9psaqP39vpnnSy2i7cTagoQSIHZpsYhS0kqiNhweBXZoi2mP 2C+kcklPKS9Qw5Jxd73t6VCWTH9Nawf2Nl5ens5afvb9rF3qkhKsn1qHL4jG3mGeQ03q nprwRVj+06TiZ+OxxJwaZbCskJMC+1Kn7F/boR0PGGe6mUuJEwKI6t+CpTFSm7qZVHwU vzAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678376874; 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=HxWSUXkz37nay0an/rvmgTRbsRs5nzwbi6ZLVuhcBk0=; b=ct8QWZeKKXoQHYiLm4IrS29aWIR87Yjsnrh5zZRdpnlg87fRn7mHMXiTQXiMTKFqsb 49K1YVkQhuWHQsCCQ33DlNp6+88ew1yxlvLNL9HXJOhEwWxDE8sRQU6TJfpnHIe3eGOS cZE4w/5NFgLknPEOs74QNCkKOAPmecUu9ezWqH52PBUzak8JE46eQYgv/0DV/gXAdi6D NEhOmfTEBnSMscEmrwMXBAVXe0ZuWmP2zeHV3Jr/VtKoBWgqx3TvQaEp3QkhUeYH0JDB NccVNvKSsb5s1BXd8GAEb/x0GBY5FKpCSTUIKjN5WJ5KV1t8tzLNJVBmIT5fNFsRUdB1 DpXg== X-Gm-Message-State: AO0yUKXBFeg+jFAxP6ve0TsyCBN1QIHlevjui5XMIAjyhfYdc62AOGhI pPCSzdmOUMPU9bqNDTCPEmImng== X-Google-Smtp-Source: AK7set9VU9ro845I1CdUVBABqEZxT0AVmCcnZy/urVr/kDQRs9+sY+Zv+femL7K5i9o0/92isH0kug== X-Received: by 2002:aca:1906:0:b0:383:fc71:110 with SMTP id l6-20020aca1906000000b00383fc710110mr10398734oii.29.1678376873761; Thu, 09 Mar 2023 07:47:53 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c0:544b:655d:5559:758d:90f7? ([2804:1b3:a7c0:544b:655d:5559:758d:90f7]) by smtp.gmail.com with ESMTPSA id m186-20020acabcc3000000b00384d3003fa3sm3539447oif.26.2023.03.09.07.47.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Mar 2023 07:47:52 -0800 (PST) Message-ID: Date: Thu, 9 Mar 2023 12:47:49 -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: Jan Kratochvil Cc: Florian Weimer , libc-alpha@sourceware.org, Anton Kozlov References: <87v8jdq7ht.fsf@oldenburg.str.redhat.com> <2659aadc-6518-cc0e-d103-84eafcbdc3f9@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=-6.2 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 09/03/23 08:32, Jan Kratochvil wrote: > On Wed, 08 Mar 2023 21:04:59 +0800, Adhemerval Zanella Netto wrote: >> Yes, without a stop-the-world scheme where a helper thread sets PR_GET_DUMPABLE >> and PTRACE_ATTACH the process can not really be sure that any new thread will not >> be created between the time you enumerate the process threads and call the 'freeze' >> function. > > That "Freezer" class does solve the race of new threads. I also do not see > a need for ptrace there, it is self-snapshotting/restoring. > https://github.com/openjdk/crac/pull/41/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR6029 I am not sure how the kernel would enumerate new tasks that are created while iterating over /proc/self/task. On closefrom Linux fallback we have a similar problem, where the code iterates over /proc/self/fd, and everytime it closes a file descriptor it lseeks back to beginning. It works because eventually there will be no more entries on /proc/self/fd, so either you will need to certify that kernel adds new tasks at the end of the getdents call (used by readdir, or lseek and keep track of all tasks already signaled. While it might work on the JVM where you can not fully control who change SIGUSR1 disposition (and I am not sure JVM would prevent a JNI call to do so), so you can't really make it generic without explicit reserve a signal to do so, similar to what glibc does for SIGCANCEL and SIGSETXID (used to synchronize setuid functions over threads). Meaning that callers of sigaction can't not explicit set such reserved signal. This is similar to what we do for SIGSETXID, so I think a proper way to do it would to do always install a new signal handler to this on pthread_create, on signal handle synchronize with proper async-signal-safe interface (pthread_mutex_lock is not, you might accomplish with sem_post but most likely you will need a atomic+futex way similar to a barrier), iterate over all dl_stack_used (so the interface can work without access to procfs), issue the signal handler or each thread, operate on the maps, then synchronize to resume threads. We can't really make it generic without accessing the internal glibc thread states. And you will also need to reallocate not only glibc, but potentially *all* libraries (since ifunc can be used by any function). > > >> I really don't think glibc should provide an interface to temporary disable any >> security hardening, it should always opt-in at either program startup or by >> building time. The ifunc mechanism is already full or corner cases and I think >> adding a runtime mechanism to reset them is *not* a way forward. >> >> As I said, I think CRIU heterogeneity should be handled by masking off the higher >> cpu features. I am not if ARCH_SET_CPUID would a solution here, it means that >> we will need to handle SIGSEGV in the loader and come up with a sane subset >> in case of failure (we now have x86_64-vx, so we can use it as default). > > So the only remaining option is that all the programs will be doing > setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...") and re-exec(). That is > a peformance kill and definitely not nice compared to any method of an IFUNC > reset. Assuming you don't reset env variable on process spawning, you can set it as default for the session. Another option would to deploy a glibc built with --disable-multi-arch; it will disable ifunc generation. And IMHO this is way nicer because this IFUNC reset as-is, without a proper stop-the-word support, is not safe and adds another corner case for the already over-complicated ifunc interface. > > >> But as Florian has said, fixing on glibc won't work consistently on other >> libraries that uses cpuid instruction. > > In Java world the other libraries (in general, there are some JNI exceptions) > do not matter as they are a Java code JIT-compiled by JVM. And this won't be a Java specific interface, but rather a GNU extension for C library. So we must make it as concise as possible, without adding any other security or undefined behavior.