linux-kernel - [RFC PATCH v2 16/19] dyndbg: ddebug_site

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 25 Dec 2020 13:19:41 -0700
From:   Jim Cromie <jim.cromie@...il.com>
To:     jbaron@...mai.com, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org
Cc:     Jim Cromie <jim.cromie@...il.com>
Subject: [RFC PATCH v2 16/19] dyndbg: ddebug_site_get/put api commentary

Paths forward: (not mutually exclusive)

A: !site -> fill from backing store

1st try at this is/was using zram.  At init, it copied each callsite
into a zs-allocation, and all site-> refs afterward went thru
_get/_put to zs-map on demand, and zs-unmap the site info.  This
worked until I tried to keep callsites mapped while they're enabled.

Another approach is to compress the new linker section, using some
algo thats good at indexed decompression.  I tried to test this a bit,
using objcopy, unsuccessfully:

   objcopy --dump-section __dyndbg_callsites=dd_callsites vmlinux.o

>From vmlinux.o it was mostly empty, vmlinux didnt have the section.

B: callsite as a set of property vectors, indexed by 'N'

We know dp is in a vector, either in the builtin __dyndbg_callsite
linker section, or the same from a modprobed one.  The builtin section
has all builtin module sub-sections catenated dogether.

At init, we iterate over the section, and "parse it" by creating a
ddebug_table for each module with prdebugs.  ddebug_table.num_debugs
remembers the size of each modules' vector of prdebugs.

We need a few things:

- _ddebug.index field, which knows offset to start of this sub-vector.
  this new field will be "free" because the struct has padding.
  it can be initialized during init, then RO.

- a back-pointer at the beginning of the sub-vector, to the
  ddebug_table "owning" (but not containing) this sub-vector of
  prdebugs.

If we had both, we could get from the ddebug element to its vector
root, back up to the owning ddebug_table, then down to the _callsite
vector, and index to the right element.  While slower than a pointer
deref, this is a cold path, and it allows elimination of the
per-callsite pointer member, thus greater density of the sections, and
still can support sparse site info.

That back-pointer feels tricky.  It needs to be 1st in the sub-vector

is to reserve the 0th slot

ing its spot at the
front of

each module's ddebug sub-vector.

getting space in the
section for it.  Initializing it is easy.

prdebugs are added to section when DECLARE_DYAMIC_DEBUG_METADATA is
compiled; its unclear whether they are intrinsically sorted during
compile, or whether thats a linker thing.

Ideally, a MODULE-mumble declaration can be coaxed into declaring a
module singleton in the section(s), either naturally at the top (or
bottom) or sorted into place.

If that doesn't work, a "preload if module is different" strategy
could maybe work, but I dont know how to do that in macros.

Signed-off-by: Jim Cromie <jim.cromie@...il.com>
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 25f49515c235..ec28c113a361 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -146,7 +146,7 @@ static void vpr_info_dq(const struct ddebug_query *query, const char *msg)

 static struct _ddebug_callsite *ddebug_site_get(struct _ddebug *dp)
 {
-	return dp->site;
+	return dp->site; /* passthru abstraction */
 }
 static inline void ddebug_site_put(struct _ddebug *dp)
 {
-- 
2.29.2