public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Jonathon Anderson <janderson@rice.edu>, libc-alpha@sourceware.org
Cc: John Mellor-Crummey <johnmc@rice.edu>,
	Ben Woodard <woodard@redhat.com>,
	Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH v8 1/4] elf: Add la_activity during application exit
Date: Fri, 31 Dec 2021 09:24:37 -0300	[thread overview]
Message-ID: <ad31b9bf-7237-e5ab-1bf5-69dbf13b3289@linaro.org> (raw)
In-Reply-To: <88fb27f5-ad6e-8f5c-8994-401e0ca1cca8@rice.edu>



On 30/12/2021 18:35, Jonathon Anderson wrote:
> 
> 
> On 12/29/21 13:54, Adhemerval Zanella wrote:
>> On 28/12/2021 14:59, Jonathon Anderson wrote:
>>> On 12/28/21 05:50, Adhemerval Zanella wrote:
>>>> +  /* The expected namespaces are one for the audit module and another for
>>>> +     the application.  */
>>> This should be 2 namespaces for the application, the audit module does not get la_* callbacks for itself. AFAICT the second namespace is used by the dlmopen call in the test body (handle_restart).
>> You are right, I forgot about the dlmopen usage.  I have adjusted the comment
>> to:
>>
>>    /* The expected namespaces are one for the audit module, one for the
>>       application, and another for the dlmopen on handle_restart.  */
> Thanks!
>>>> +      /* The cookie identifies the object at the head of the link map,
>>>> +         so we only add a new namespace if it changes from previous
>>>> +         one.  */
>>>> +      if (last_act == LA_ACT_ADD && acts[nacts - 1] != cookie)
>>>> +        acts[nacts++] = cookie;
>>> This works since the dlmopen is second/last in the test body. If there was another dlopen this would consider it a third namespace. Should this be noted in the comment?
>> I thin it is worth to comment it, I have changed the comment to:
>>
>>   /* The cookie identifies the object at the head of the link map,
>>      so we only add a new namespace if it changes from previous
>>      one.  This work since dlmopen is the last in the test body.  */
> Thanks!
>>>> +      /* The LA_ACT_DELETE is called in the reverse order of
>>>> +         LA_ACT_ADD.  */
>>>> +      else if (last_act == LA_ACT_DELETE && cookie != last_act_cookie)
>>>> +        {
>>>> +          last_act_cookie = acts[--nacts];
>>>> +          TEST_COMPARE (acts[nacts], cookie);
>>>> +          acts[nacts] = 0;
>>>> +        }
>>> Not sure about this one yet. Is this always the case or only because there are exactly 2 audited namespaces?
>>>
>>> Also, this works since la_activity(LA_ACT_DELETE) is only called at program termination. If dlclose was called in the test body (or a dlopen of a library missing dependencies) this might fail. Should this be noted in the comment?
>> Yeah, this works because there is no dlclose before program termination
>> and tst-audit23mod.so does not have any dependency not already mapped.
>> I have changed the comment to:
>>
>>   /* The LA_ACT_DELETE is called in the reverse order of LA_ACT_ADD
>>      at program termination (if the tests adds a dlclose or a library
>>      with extra dependencies this require to be adapted).  */
> Thanks!
>>>> +      /* la_objclose should be called after la_activity(LA_ACT_DELETE) for
>>>> +         the closed object's namespace.  */
>>>> +      TEST_COMPARE (last_act, LA_ACT_DELETE);
>>>> +      if (last_act_cookie != 0)
>>>> +        {
>>>> +          TEST_COMPARE (last_act_cookie, cookie);
>>>> +          last_act_cookie = 0;
>>>> +        }
>>> This works because the la_objclose order for program termination is the same as the order in the link map (implementation detail), and because la_objclose is only called during program termination in this test. If dlclose was called in the test body this would fail. Should this be noted in the comment?
>> I think it makes way more sense to tie to the DT_FINI/DT_FINI_ARRAY execution
>> order, but I agree it is an implementation detail (we could just iterate over
>> the namespace lists and call it for each objects as well).
> Is that the same order in the end? IIUC there was a patch posted to reorder DT_FINI to be the opposite of DT_INIT order: https://sourceware.org/pipermail/libc-alpha/2021-December/134167.html

Florian's patch fixes it for dlclose, my understanding is it should not
really interfere with this test in specific.  I would probably review
this set next week and check if I would need to adapt the audit tests.

> 
> I agree DT_FINI order makes much more sense.
>> I think the above comments it should be clear that if someone want to test
>> dlclose or shared objects with more dependencies, the tests will need to be
>> adapted.
> Agreed.
>>>> +  /* la_activity(LA_ACT_CONSISTENT) should be the last callback received for
>>>> +     every namespace.  */
>>>> +  TEST_COMPARE (last_act, LA_ACT_CONSISTENT);
>>> This only checks the last la_activity notification (AFAICT the main namespace), rather than the last for each namespace.
>>>> +  /* Sanity check to check if all LA_ACT_DELETE are matched with
>>>> +     la_objclose.  */
>>>> +  TEST_COMPARE (last_act_cookie, 0);
>>> Similarly, this only checks the last LA_ACT_DELETE notification, rather than last for each namespace.
>> Indeed I agree we can increase the coverage of both tests, I have added
>> a better la_activity and LA_ACT_DELETE one.
> Thanks, but (unless I'm missing something) I'm not seeing the increased coverage. There is a new check that LA_ACT_CONSISTENT is always preceded by a matching LA_ACT_* (thanks!), but the check that LA_ACT_DELETE is matched with la_objclose is gone and there isn't a check that LA_ACT_CONSISTENT is received for every namespace.

Indeed, it only now checks if the last cookie from la_activity matches the
the first la_objclose.  I will add a check for the la_activity flag as well.

> 
> I think adjusting the la_activity logic as below would catch these last couple of cases (although the first check is also AFAIK an undocumented implementation detail):
> 
>     uintptr_t cookie;
>     int this_act;
>     int r = sscanf (buffer + strlen ("la_activity: "),
>                     "%d %"SCNxPTR"", &this_act, &cookie);
>     TEST_COMPARE (r, 2);
> 
>     /* The cookie identifies the object at the head of the link map.
>        Only one link map may be not-CONSISTENT at a time.  */
>     if (cookie != last_act_cookie && last_act_cookie != -1)
>        TEST_COMPARE (last_act, LA_ACT_CONSISTENT);
> 
>     if (this_act == LA_ACT_ADD && ...
>     ...
>     /* LA_ACT_CONSISTENT must be preceded by a matching LA_ACT_ADD
>        or LA_ACT_DELETE for the same link map.  */
>     else if (this_act == LA_ACT_CONSISTENT)
>       {
>         TEST_COMPARE (cookie, last_act_cookie);
> 
>         /* LA_ACT_DELETE must always be followed by an la_objclose. */
>         if (last_act == LA_ACT_DELETE)
>           TEST_COMPARE (first_objclose, true);
>         else
>           TEST_COMPARE (last_act, LA_ACT_ADD);
>       }
> 
>     last_act = this_act;
>     first_objclose = false;
>>

Thanks, I added these checks on the patch.

>> Below it is the updated version:
> Thank you! Below are my more minor nits:
>>
>> -- 
>>
>> +
>> +  /* The expected namespaces are one for the audit module, one for the
>> +     application, and another for the dlmopen on handle_restart.  */
>> +  enum { max_ns = 3 };
>> +  uintptr_t acts[max_ns];
>> +  size_t nacts = 0;
>> +  int last_act = -1;
>> +  uintptr_t last_act_cookie = -1;
>> +  bool first_objclose = false;
> Naming nit: should this variable be `seen_first_objclose` or `seen_objclose`? It seems to be inverted from "first."

Yeah, it does make more sense. I changed to seen_first_objclose.

>> +
>> +  FILE *out = fmemopen (result.err.buffer, result.err.length, "r");
>> +  TEST_VERIFY (out != NULL);
>> +  char *buffer = NULL;
>> +  size_t buffer_length = 0;
>> +  while (xgetline (&buffer, &buffer_length, out))
>> +    {
>> +      printf ("%s", buffer);
>> +      if (startswith (buffer, "la_activity: "))
>> +    {
>> +      uintptr_t cookie;
>> +      int r = sscanf (buffer + strlen ("la_activity: "),
>> +              "%d %"SCNxPTR"", &last_act, &cookie);
>> +      TEST_COMPARE (r, 2);
>> +      /* The cookie identifies the object at the head of the link map,
>> +         so we only add a new namespace if it changes from previous
>> +         one.  This work since dlmopen is the last in the test body.  */
>> +      if (last_act == LA_ACT_ADD && acts[nacts - 1] != cookie)
>> +        {
>> +          acts[nacts++] = cookie;
>> +          last_act_cookie = cookie;
>> +        }
>> +      /* The LA_ACT_DELETE is called in the reverse order of LA_ACT_ADD
>> +         at program termination (if the tests adds a dlclose or a library
>> +         with extra dependencies this require to be adapted).  */
>> +      else if (last_act == LA_ACT_DELETE) // && cookie != last_act_cookie)
> Code in a comment here? Since there are no libraries with missing dependencies the commented clause is not needed.

I forgot to remove this comment in fact.

>> +        {
>> +          last_act_cookie = acts[--nacts];
>> +          TEST_COMPARE (acts[nacts], cookie);
>> +          acts[nacts] = 0;
>> +        }
>> +      else if (last_act == LA_ACT_CONSISTENT)
>> +        TEST_COMPARE (cookie, last_act_cookie);
>> +
>> +      first_objclose = false;
>> +    }
>> +      else if (startswith (buffer, "la_objopen: "))
>> +    {
>> +      char *lname;
>> +      uintptr_t laddr;
>> +      Lmid_t lmid;
>> +      uintptr_t cookie;
>> +      int r = sscanf (buffer + strlen ("la_objopen: "),
>> +              "%"SCNxPTR"  %ms %"SCNxPTR" %ld", &cookie, &lname,
>> +              &laddr, &lmid);
>> +      TEST_COMPARE (r, 4);
>> +
>> +      /* la_objclose is not triggered by vDSO because glibc does not
>> +         unload it.  */
>> +      if (is_vdso (lname))
>> +        continue;
>> +      if (nobjs == max_objs)
>> +        FAIL_EXIT1 ("non expected la_objopen: %s %"PRIxPTR" %ld",
>> +            lname, laddr, lmid);
>> +      objs[nobjs].lname = lname;
>> +      objs[nobjs].laddr = laddr;
>> +      objs[nobjs].lmid = lmid;
>> +      objs[nobjs].closed = false;
>> +      nobjs++;
>> +
>> +      first_objclose = false;
> IIUC this indirectly checks that la_objopen always comes before la_objclose between la_activity calls. Does it need a comment and/or a more explicit check?

I added a note, thanks.

>> +    }
>> +      else if (startswith (buffer, "la_objclose: "))
>> +    {
>> +      char *lname;
>> +      uintptr_t laddr;
>> +      Lmid_t lmid;
>> +      uintptr_t cookie;
>> +      int r = sscanf (buffer + strlen ("la_objclose: "),
>> +              "%"SCNxPTR" %ms %"SCNxPTR" %ld", &cookie, &lname,
>> +              &laddr, &lmid);
>> +      TEST_COMPARE (r, 4);
>> +
>> +      for (size_t i = 0; i < nobjs; i++)
>> +        {
>> +          if (strcmp (lname, objs[i].lname) == 0 && lmid == objs[i].lmid)
>> +        {
>> +          TEST_COMPARE (objs[i].closed, false);
>> +          objs[i].closed = true;
>> +          break;
>> +        }
>> +        }
>> +
>> +      /* la_objclose should be called after la_activity(LA_ACT_DELETE) for
>> +         the closed object's namespace.  */
>> +      TEST_COMPARE (last_act, LA_ACT_DELETE);
>> +      if (!first_objclose)
>> +        {
>> +          TEST_COMPARE (last_act_cookie, cookie);
>> +          first_objclose = true;
>> +        }
>> +    }
>> +    }
>> +
>> +  for (size_t i = 0; i < nobjs; i++)
>> +    {
>> +      TEST_COMPARE (objs[i].closed, true);
>> +      free (objs[i].lname);
>> +    }
>> +
>> +  /* la_activity(LA_ACT_CONSISTENT) should be the last callback received for
>> +     every namespace.  */
>> +  TEST_COMPARE (last_act, LA_ACT_CONSISTENT);
> The comment here still seems misleading given the check. If you use something like the logic suggested above, maybe this should read something like:
> 
>     /* la_activity(LA_ACT_CONSISTENT) should be the last callback received.
>        Since only one link map may be not-CONSISTENT at a time, this also
>        ensures la_activity(LA_ACT_CONSISTENT) is the last callback received
>        for every namespace.  */

It is indeed better, thanks.

>> +
>> +  free (buffer);
>> +  xfclose (out);
>> +
>> +  return 0;
>> +}
>> +
>> +#define TEST_FUNCTION_ARGV do_test
>> +#include <support/test-driver.c>

  reply	other threads:[~2021-12-31 12:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-28 11:50 [PATCH v8 0/4] Multiple rtld-audit fixes Adhemerval Zanella
2021-12-28 11:50 ` [PATCH v8 1/4] elf: Add la_activity during application exit Adhemerval Zanella
2021-12-28 17:59   ` Jonathon Anderson
2021-12-29 19:54     ` Adhemerval Zanella
2021-12-30 21:35       ` Jonathon Anderson
2021-12-31 12:24         ` Adhemerval Zanella [this message]
2021-12-28 11:50 ` [PATCH v8 2/4] elf: Fix initial-exec TLS access on audit modules (BZ #28096) Adhemerval Zanella
2021-12-31 12:25   ` Adhemerval Zanella
2021-12-28 11:50 ` [PATCH v8 3/4] elf: Issue la_symbind for bind-now (BZ #23734) Adhemerval Zanella
2021-12-28 11:50 ` [PATCH v8 4/4] elf: Fix runtime linker auditing on aarch64 (BZ #26643) Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad31b9bf-7237-e5ab-1bf5-69dbf13b3289@linaro.org \
    --to=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    --cc=janderson@rice.edu \
    --cc=johnmc@rice.edu \
    --cc=libc-alpha@sourceware.org \
    --cc=woodard@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).