From: Nick Alcock <redacted>
Date: Thu, 20 Jul 2023 14:00:46 +0100

On 19 Jul 2023, Alexander Lobakin verbalised:

"verbalised", I like that one :D

quoted

From: Nick Alcock <redacted>
Date: Wed, 19 Jul 2023 12:12:06 +0100

quoted

quoted

Yes, please coordinate with Nick and review each other's work, now we
have two separate efforts with different reasons but hopefully we'll

Three efforts[0] :D Mine went unnoticed unfortunately, so I switched to
other projects then.

It's odd, nobody seems to have noticed these until recently and now
suddenly people are crawling out of the woodwork wanting unique
addresses :) maybe the ambiguous ones are just getting commonplace
enough that they're biting people more often?

I read kbuild, modules and livepatching lists time to time. That means,
some small patch with no discussion can be easily missed by me, but not
some big series or when there's a lot of comments.

But it was strange and funny back then, in the FG-KASLR thread some devs
asked me to implement unique kallsyms before moving forward ("symbol
position" means nothing when this "position" is random each boot), I
posted that RFC I linked in the previous reply and then... silence. "We
want it so much so that we don't care" :D

quoted

My idea was to give relative path from the kernel root to the objfile,
as we have a good bunch of non-unique "filename + symbol name" pairs.

I considered that, but unfortunately that has two problems to a raging
perfectionist like me:

 - the objfile probably won't exist except if you're actually doing
   kernel development, since kernel build trees are big enough that a
   lot of people delete them after building or ship kernels to other
   machines: if someone else built your kernel (overwhelmingly common
   among non-kernel-devs) the objfiles are sure to be absent. (But an
   option to not truncate the names when you know they won't be absent
   might be a good idea, though this pushes space requirements up by
   hundreds of kilobytes so it should probably be off by default.)

 - even giving a path to the kernel module on disk (much lower
   resolution and vulnerable to ambiguity again) is unreliable because
   there's absolutely no guarantee that any given process can see any of
   them: they might be in a different fs namespace or the modules might
   only be present in an initramfs (hell, I even know setups which
   *compile* the modules needed for rootfs mounting in the initramfs!
   Yes this is borderline insane, yes it happens). More commonly, they
   might be compressed using any of a number of compressors, changing
   the name, and the kernel has no idea which compressor might have been
   used (not unless you want it to go and look, and, well, wandering
   around over the fs hunting down .ko.* files from kernelspace to get
   their names right is *not* my idea of a good time! It's hard enough
   to get that right from userspace, honestly, even with kmod helping.)

   The most you could do would be to provide a key you could use with
   kmod to dig the real modules out from userspace. Partial names are as
   good as anything for that :)

So all the objfile names are, when it comes down to it, is names with no
intrinsic meaning: even if they're filenames of some kind, tools can't
rely on being able to access those files. (For my most common use case,
using a tracer on an enterprise-built production kernel, they'd almost
never be able to.)

So you might as well treat the objfile names as arbitrary string keys
that might be a memory-jogger for humans, which means you can chop
boring bits off them to save space :)

Oh, maybe I phrased it badly, I was saving C source file path actually,
not objfile :D Like:

0xdeadbeef net/core/dev.c:napi_complete_done

Thanks,
Olek