Re: Zenbleed

On 23. 7. 27., mike tancsa wrote:
> 
> On 7/27/2023 4:03 PM, Jung-uk Kim wrote:
>>
>> Please try the attached patch.  It should fix the sched_getcpu() issue.
>>
>> Jung-uk Kim
> 
> 
> Thank you for helping me with this. However, still the following error 
> on RELENG_12 from a few days ago
> 
> % git clone "https://git.hardenedbsd.org/shawn.webb/zenbleed"
> Cloning into 'zenbleed'...
> warning: redirecting to 
> https://git.hardenedbsd.org/shawn.webb/zenbleed.git/
> remote: Enumerating objects: 23, done.
> remote: Total 23 (delta 0), reused 0 (delta 0), pack-reused 23
> Receiving objects: 100% (23/23), 15.74 KiB | 15.74 MiB/s, done.
> Resolving deltas: 100% (8/8), done.
> % cd zenbleed/
> % cat - > p
> --- pattern.c   2023-07-23 10:45:32.000000000 -0400
> +++ pattern.c   2023-07-27 13:44:38.238159000 -0400
> @@ -6,13 +6,14 @@
>   #include <stdbool.h>
>   #include <x86intrin.h>
>   #include <sched.h>
> +#ifdef __linux__
>   #include <syscall.h>
> +#endif
>   #include <err.h>
>   #include <pthread.h>
>   #include <assert.h>
>   #include <ctype.h>
>   #include <signal.h>
> -#include <sys/sysinfo.h>
> 
>   #include "zenbleed.h"
> 
> @@ -82,7 +83,7 @@ void * pattern_leak_consumer(void *param)
>               }
>           }
> 
> -        fprintf(stdout, "%.*s", matchlen, matchptr);
> +        fprintf(stdout, "%.*s", (int)matchlen, matchptr);
> 
>           // If the match is bigger than our pattern size, we skip to 
> the end of it.
>           if (matchlen > patlen) {
> --- util.c.orig 2023-07-23 10:45:32.000000000 -0400
> +++ util.c      2023-07-27 13:44:38.238234000 -0400
> @@ -46,6 +46,9 @@ bool num_inrange(char *range, int num)
>   bool num_inrange(char *range, int num)
>   {
>       char *r, *s, *e;
> +#ifndef __linux__
> +    size_t len;
> +#endif
> 
>       // Example:
>       // 1,2,3,4-8,2
> @@ -53,7 +56,14 @@ bool num_inrange(char *range, int num)
>       if (range == NULL)
>           return false;
> 
> -    s = strtok_r(strdupa(range), ",", &r);
> +#ifndef __linux__
> +    len = strlen(range) + 1;
> +    s = alloca(len);
> +    memcpy(s, range, len);
> +#else
> +    s = strdupa(range);
> +#endif
> +    s = strtok_r(s, ",", &r);
> 
>       while (s) {
>           int start;
> --- zenbleed.c.orig     2023-07-23 10:45:32.000000000 -0400
> +++ zenbleed.c  2023-07-27 15:33:03.131825000 -0400
> @@ -6,13 +6,17 @@
>   #include <stdbool.h>
>   #include <x86intrin.h>
>   #include <sched.h>
> +#ifdef __FreeBSD__
> +#include <sys/param.h>
> +#include <pthread_np.h>
> +#else
>   #include <syscall.h>
> +#endif
>   #include <err.h>
>   #include <pthread.h>
>   #include <assert.h>
>   #include <ctype.h>
>   #include <signal.h>
> -#include <sys/sysinfo.h>
> 
>   #include "zenbleed.h"
> 
> @@ -129,6 +133,16 @@ static void * thread_leak_consumer(void *param)
>       return 0;
>   }
> 
> +#if defined(__FreeBSD_version) && __FreeBSD_version < 1300524
> +static __inline int sched_getcpu(void)
> +{
> +    register_t cpu;
> +
> +    __asm("rdpid %0" : "=r" (cpu));
> +    return (int)cpu;
> +}
> +#endif
> +
>   // The main leaking loop, it just keeps waiting for a leak and then 
> sends it to
>   // the consumer thread to be printed.
>   static void * thread_leak_producer(void *param)
> @@ -298,7 +312,7 @@ int main(int argc, char **argv) {
>       }
> 
>       // We spawn a thread on every evailable core and start leaking to 
> see what we get.
> -    ncpus   = get_nprocs();
> +    ncpus = sysconf(_SC_NPROCESSORS_ONLN);
>       thread_arg_t* args = calloc(sizeof(thread_arg_t), ncpus);
>       threads = calloc(sizeof(pthread_t), ncpus);
> 
> 
> % patch -p1 < p
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |--- pattern.c  2023-07-23 10:45:32.000000000 -0400
> |+++ pattern.c  2023-07-27 13:44:38.238159000 -0400
> --------------------------
> Patching file pattern.c using Plan A...
> Hunk #1 succeeded at 6.
> Hunk #2 succeeded at 83.
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |--- util.c.orig        2023-07-23 10:45:32.000000000 -0400
> |+++ util.c     2023-07-27 13:44:38.238234000 -0400
> --------------------------
> Patching file util.c using Plan A...
> Hunk #1 succeeded at 46.
> Hunk #2 succeeded at 56.
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |--- zenbleed.c.orig    2023-07-23 10:45:32.000000000 -0400
> |+++ zenbleed.c 2023-07-27 15:33:03.131825000 -0400
> --------------------------
> Patching file zenbleed.c using Plan A...
> Hunk #1 succeeded at 6.
> Hunk #2 succeeded at 133.
> Hunk #3 succeeded at 312.
> Hmm...  Ignoring the trailing garbage.
> done
> % gmake
> nasm  -O0 -felf64 -o zenleak.o zenleak.asm
> cc -O0 -ggdb3 -march=znver2   -c -o pattern.o pattern.c
> cc -O0 -ggdb3 -march=znver2   -c -o workqueue.o workqueue.c
> cc -O0 -ggdb3 -march=znver2   -c -o util.o util.c
> cc -O0 -ggdb3 -march=znver2  -pthread -Wl,-z,noexecstack zenbleed.c 
> zenleak.o pattern.o workqueue.o util.o   -o zenbleed
> zenbleed.c:153:5: error: unknown type name 'cpu_set_t'; did you mean 
> 'cpuset_t'?
>      cpu_set_t mask;
>      ^~~~~~~~~
>      cpuset_t
> /usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
> typedef struct _cpuset cpuset_t;
>                         ^
> zenbleed.c:213:5: error: unknown type name 'cpu_set_t'; did you mean 
> 'cpuset_t'?
>      cpu_set_t set;
>      ^~~~~~~~~
>      cpuset_t
> /usr/include/sys/_cpuset.h:50:24: note: 'cpuset_t' declared here
> typedef struct _cpuset cpuset_t;
>                         ^
> zenbleed.c:221:51: error: use of undeclared identifier 'cpu_set_t'
>      if (pthread_attr_setaffinity_np(&attr, sizeof(cpu_set_t), &set) != 0)
>                                                    ^
> 3 errors generated.
> gmake: *** [<builtin>: zenbleed] Error 1
> %
> 
Can you please the attached patch?  Sorry about the trouble.

Jung-uk Kim