[libc-commits] [libc] [libc] Add program_invocation(_short)_name and tweak err.h functions (PR #212448)

[Pavel Labath via libc-commits]

================
@@ -0,0 +1,103 @@
+//===-- Integration test for program_invocation_name ---------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "src/errno/program_invocation_name.h"
+#include "src/errno/program_invocation_short_name.h"
+#include "src/unistd/execve.h"
+#include "test/IntegrationTest/test.h"
+
+static bool my_streq(const char *lhs, const char *rhs) {
+  const char *l, *r;
+  for (l = lhs, r = rhs; *l != '\0' && *r != '\0'; ++l, ++r)
+    if (*l != *r)
+      return false;
+
+  return *l == '\0' && *r == '\0';
+}
+
+TEST_MAIN(int argc, char **argv, char **envp) {
----------------
labath wrote:

Added a test for a tralining '/'.

A null argv[0] is an interesting question. The behavior here depends on the kernel. Kernels >=5.17, as well as up-to-date LTS branches have the CVE-2021-4034 [mitigation](https://lkml.org/lkml/2022/4/5/275), which forces argv[0] to "". If we see a null here, it means someone's running an old kernel without recent security fixes.

I see three options:
- add the test, have it assert program name (and  argv[0]) is "", let the test fail on old systems
- add the test, have it assert program name is "", and add an independent mitigation, so that the null argv[0] exploits are mitigated even on old kernels
- add an test, have it assert that the value is "" or nullptr, let the host kernel determine the behavior.

The second one is safest, and doesn't cost much, so it's probably the best. If you agree, I'll spin up a separate patch for that.

https://github.com/llvm/llvm-project/pull/212448