From nobody Thu Jul 27 20:30:20 2023 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4RBj7f2rD8z4prg3 for ; Thu, 27 Jul 2023 20:30:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RBj7f102Lz3lFR; Thu, 27 Jul 2023 20:30:22 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.17.1/8.16.1) with ESMTPS id 36RKUJjM049238 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Thu, 27 Jul 2023 16:30:19 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4::29] ([IPv6:2607:f3e0:0:4:0:0:0:29]) by pyroxene2a.sentex.ca (8.16.1/8.15.2) with ESMTPS id 36RKUIhk099104 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 27 Jul 2023 16:30:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: Date: Thu, 27 Jul 2023 16:30:20 -0400 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: Zenbleed Content-Language: en-US To: Jung-uk Kim , Shawn Webb , 0x1eef <0x1eef@protonmail.com> Cc: "freebsd-security@freebsd.org" References: <20230726214636.yblem2s4sgapb6cw@mutt-hbsd> <5ca207d8-b947-12da-46b2-f83e55fcc98c@sentex.net> From: mike tancsa In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 X-Rspamd-Queue-Id: 4RBj7f102Lz3lFR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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  #include  #include +#ifdef __linux__  #include +#endif  #include  #include  #include  #include  #include -#include  #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  #include  #include +#ifdef __FreeBSD__ +#include +#include +#else  #include +#endif  #include  #include  #include  #include  #include -#include  #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: *** [: zenbleed] Error 1 %