On Mon, 22 Jan 2024 12:14:36 -0500[...]
Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:
On my 6.1.0 kernel:
find /sys/kernel/tracing | wc -l
15598
(mainly due to TRACE_EVENT ABI files)
Hashing risks:
- Exposing kernel addresses if the hashing algorithm is broken,
Well this was my biggest concern, but if I truncate at least a nibble, with
the unique salt to the algorithm for each file, how easily does that expose
kernel addresses.
The ei itself, is created from kmalloc() so you would at best get a heap
address. But with the missing nibble (if I mask it with ((1 << 28) - 1),
and much more taken away for 64 bit systems), and the added unique salt, is
it possible for this to expose anything that could be used in an attack?
- Collisions if users are unlucky (which could trigger those
'find' errors).
Those 15598 inode values fit within a single page (bitmap of
1922 bytes).
So I would recommend simply adding a bitmap per tracefs filesystem
instance to keep track of inode number allocation.
And how do I recover this bit after the inode is freed, but then referenced
again?
Creation/removal of files/directories in tracefs should not be
a fast-path anyway, so who cares about the speed of a find first
bit within a single page ?
When an inode is no longer referenced, it is freed. When it is referenced
again, I want it to be recreated with the same inode number it had
previously. How would having a bitmask help with that? I need a way to map
an ei structure with a unique number without adding another 4 bytes to the
structure itself.