linux-kernel - Re: [FEATURE REQUEST] tracing: Have event filters handle dynamic arrays

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 25 Nov 2020 09:16:52 -0600
From:   Tom Zanussi <zanussi@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>, Daniel Wagner <wagi@...om.org>
Subject: Re: [FEATURE REQUEST] tracing: Have event filters handle dynamic
 arrays

Hi Steve, Daniel,

On Tue, 2020-11-24 at 11:37 -0500, Steven Rostedt wrote:
> Hi Tom,
> 
> Daniel asked about filtering bitmasks, something like:
> 
>    cpumask != 0xff
> 
> Looking into the code, I realized that bitmasks are dynamic arrays,
> and
> there's no logic in the filter code to handle dynamic arrays of
> anything
> other than 'char' type (which are dynamic strings).
> 
> If you have any cycles to spare, do you think you can add code to
> process
> dynamic arrays other than char?
> 
> The compare logic may be complex though. I think the above example
> should
> work, but we would need to define how that happens.
> 
> I guess we should follow the cpumask logic, and break all non string
> dynamic arrays up into 32 bit words. Even if something is defined as
> u8, it
> will be converted to the local endian of the machine. Basically, we
> should
> follow the function bitmap_string() defined in lib/vsnprintf.c
> 
> If we have a u8 dynamic array of:
> 
>  0x12 0x34 0x56 0x78 0x9a 0xbc 0xde 0xf0
> 
> On a little endian machine it would match:
> 
>   0xf0debca9,0x78563412
> 
> This way, if we have a machine with 64 CPUS, and we want to match
> cpus 0-7,
> then we only need to do:
> 
>   cpumask & 0xff
> 
> The above would be equivalent to:
> 
>  cpumask & 0,0xff
> 
> in such a case.
> 
> That's because, if I'm reading the code correctly, a cpumask for CPUs
> 0-7
> bits set for 64 CPU machine in raw format would be:
> 
>  0x00 0x00 0x00 0xff 0x00 0x00 0x00 0x00
> 
> The dynamic arrays will allow comma separated 4 byte words to match.
> 
> Daniel brought this up, and he said he'd be willing to help out
> making a
> patch if he has spare cycles to spare. Perhaps, between the two of
> you, you
> could come up with the cycles to produce such a patch :-)
> 

Sure, I can take a look - luckily holidays are coming up so should be
able to find some time for this.

Tom

> Cheers,
> 
> -- Steve