From: Jonathon Anderson <janderson@rice.edu>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
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: Thu, 30 Dec 2021 15:35:25 -0600 [thread overview]
Message-ID: <88fb27f5-ad6e-8f5c-8994-401e0ca1cca8@rice.edu> (raw)
In-Reply-To: <1da21f47-10df-bc0f-ca21-3e32b389eca6@linaro.org>
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
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.
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;
>
> 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."
> +
> + 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.
> + {
> + 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?
> + }
> + 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. */
> +
> + free (buffer);
> + xfclose (out);
> +
> + return 0;
> +}
> +
> +#define TEST_FUNCTION_ARGV do_test
> +#include <support/test-driver.c>
next prev parent reply other threads:[~2021-12-30 21:35 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 [this message]
2021-12-31 12:24 ` Adhemerval Zanella
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=88fb27f5-ad6e-8f5c-8994-401e0ca1cca8@rice.edu \
--to=janderson@rice.edu \
--cc=adhemerval.zanella@linaro.org \
--cc=fweimer@redhat.com \
--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).