From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id 2C87D3858C3A for ; Tue, 21 Dec 2021 17:38:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2C87D3858C3A Received: by mail-qt1-x836.google.com with SMTP id a1so13515672qtx.11 for ; Tue, 21 Dec 2021 09:38:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=mvt5UrJ7zkevE5tft2tIpV4jY3zEwGWykDxcJvIm99w=; b=mFG4WRrfW12bsqoFZkDFwGsHJAGcewKuNMdZeBHB3wrbHcCdjyd8JwFU8WpZFU0xLz FqeAikzaUC59xStrM8F4u69EiEcN9wGIBVADvwSIhRjHhVfIYjIYVxZ9jGt2o1B2yB2W 9z6gs5pzFEH1ZPgFTD9g0iYFNzyAKYiXR5ROR69cibfZRabOKZGPLCdE2cd94AjpJpl6 dOZCOa8EO1esO2SPJcyTDHIdXaX6f9R4rIJoGzDOQSJLoolUrf05gcgLUlbr9goetovO ML8lp4S3ZHMq7iEtEd8Y39P2o1VscICo6DhA31indYDwsZQXuch51cCpuwro3G3nSCY9 iISQ== X-Gm-Message-State: AOAM533j5DDD2BkKvck/5NOxJMx/S3AsnqwId+sscssq9CpdQi/D+uAE oXsynR3hhZYjb8V272N3CvCEz7MljQuWzw== X-Google-Smtp-Source: ABdhPJwgKMmdIc/NWbbu1SwJY7v64skGD3vIHGgqZXueWvohCC5yP+6W/pz5gjcFesQbKA+LCQmp7w== X-Received: by 2002:a05:622a:2c9:: with SMTP id a9mr3208925qtx.28.1640108336755; Tue, 21 Dec 2021 09:38:56 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:3b1e:8bd2:32a9:e2a3:1842? ([2804:431:c7cb:3b1e:8bd2:32a9:e2a3:1842]) by smtp.gmail.com with ESMTPSA id j20sm17413513qtj.43.2021.12.21.09.38.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Dec 2021 09:38:56 -0800 (PST) Message-ID: Date: Tue, 21 Dec 2021 14:38:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH v6 19/20] elf: Fix runtime linker auditing on aarch64 (BZ #26643) Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org, John Mellor-Crummey , Ben Woodard References: <20211115183734.531155-1-adhemerval.zanella@linaro.org> <20211115183734.531155-20-adhemerval.zanella@linaro.org> <87zgovc68b.fsf@oldenburg.str.redhat.com> <87mtku9fvd.fsf@oldenburg.str.redhat.com> <87ee669fey.fsf@oldenburg.str.redhat.com> <87r1a598l2.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: <87r1a598l2.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.5 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Dec 2021 17:38:59 -0000 On 21/12/2021 14:22, Florian Weimer wrote: > * Adhemerval Zanella: > >> On 21/12/2021 11:54, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>>>> At least for aarch64 old audit modules are error-prone and potentially adds >>>>>> more subtle issues since they do not save/restore some return register that >>>>>> I don't see any real gain to keep supporting them. >>>>> >>>>> I disagree. la_objsearch alone is a significant use case, and I don't >>>>> see why it wouldn't work today. It does not need any >>>>> architecture-specific code whatsoever. >>>> >>>> My main problem is provide a API which undocumented and missing support >>>> where if users tries to replicate what other architecture does it will >>>> shoot in the foot. I think this is just a broken API and we should >>>> avoid it. >>> >>> Sorry, which API? >> >> THe audit modules one, making la_objsearch work when the rest of the possible >> callbacks functions might trigger undefined behavior (as per BZ#26643) does >> not seems to me as as good way forward. It has not bitten us before because >> the user case is quite limited. > > Red Hat has at least one customer that only uses la_objsearch and not > la_symbind (but they don't use aarch64, so they aren't impacted by this > bug either way). > > However, you are changing generic code, so what you are proposing > rejects all old audit modules on all architectures. This is really not > the way to do this. Yes, I agree that changing the generic code was kind unnecessary on most architectures. > > Let me summarize my recommendation: > > . Change LAV_CURRENT to 2. > > . Treat la_version return values 1 and 2 the same for now (so > as > before in the check, not !=). And that is what I am doing now. > > . *If* a user shows up whose aarch64 audit modules were broken by the > fix for bug 26643, support two ABIs for the PLT enter/exit hooks. And that is what I really dislike and I want to avoid, I see absolute no gain about supporting an interface for aarch64 (or any other port, the issue is only aarch64 is currently showing) that has subtle and broken API. For aarch64 I still think it better to just avoid loading old audit modules. > > . Consider issuing more la_symbind callbacks for LAV_CURRENT == 2 > only (BIND_NOW functions and basically all symbols). > What about newer audit module version that request PLT trace? Currently my plan is to stop execution with an error, instead of just ignoring it.