It looks into the cmd line it was invoked with, then generates the path based on the u-arch, and then exec the actual binary. There are total two fork/exec: one to launch the hwcaps-loader (what /usr/bin/foo points to), and the fork-exec that hwcaps-loader does to run the actual binary.

I'm too thinking about the impact on observability and security complexity, but I guess it would be a small amount packages adopting this.

On 1/12/25 1:25 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Jan 12, 2025 at 03:16:39PM -0500, Neal Gompa wrote:
On Sun, Jan 12, 2025 at 2:36 PM Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
On Sun, Jan 12, 2025 at 05:21:18PM +0100, Vitaly Zaitsev via devel wrote:
On 12/01/2025 13:02, Christoph Erhardt wrote:
1. Not all packages but only those whose maintainers explicitly opt in.
Yes, at the first stage. But over time the number of packages can increase
significantly.
I think any massive use of this scheme is unlikely. Note that we'd
want to this only for packages where the optimized code yields
noticeable benefits. There just aren't that many packages which do
significant number crunching _and_ don't already use some kind of
runtime cpu detection.

2. The duplication will affect only the executable ELFs - i.e. the
contents of `/usr/bin` - shipped by these packages. There will be no
duplication of shared libraries, data files or anything else.
Shared libraries used by affected packages should also be rebuilt with these
optimizations. For example, Firefox has most of its logic in *.so files.

One effect this *will* have is a slightly increased latency for
launching an affected program.
How much?
Benchmarks indicate 100–1000 μs.
My concern is that this defeats most methods of observability. It's
essentially the same as the double-fork problem we used to have with
system services. The stub will fork out and exec a new binary, which
means you lose track of the binary and can't reliably trace it.
Why do you think it would fork? There should be just one process
that executes the loader code and then something else.

Zbyszek

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to