From nobody Sat Jan 15 23:25:45 2022 X-Original-To: freebsd-current@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 47908195EC56 for ; Sat, 15 Jan 2022 23:25:59 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JbvRp0Z0yz3h0F for ; Sat, 15 Jan 2022 23:25:58 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642289149; bh=6GjEcx4peSYXxhtDeDKaAM/YBQL2b85G6mUDmlfzGzE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=oDU1D5Pl2goXFxGRJxXo/elXSiFY+bdRJRxUjQAKIl1WPh5GXOMqAdQn/ph+cYIIWVshZPRKIh3E/JUeA/37VuXvAb3jxELupNds1WhP7hvTNrXJvIxgsoo0Va2BWRZLEMo4pcl79ysgf4bhz0w+0eKVO4ld83nRbT8SvP2RqxJYKwvmH6KKt8pqatZc1/gMcW3wr5AohUKhQTpQmTeLh01qKGLiEfBM24c9pkYZvxYcV6RpeGm3RAdEcOvIgRZTY4TNByVTp6gqIyaLA6ie24qpfZYb5fSRu9NahVXW3wLmG/axhTcB7beuJsaD95rrKJyqKaEqFsXKPxNjUv2O+Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642289149; bh=DeN4umjdMgtKbdHLPn7LbgymKH9sukvq1Oxu8zS0Nx+=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=ZlouJLmFzMvvMi9xSK7sbsS30KfmbiqbnqwjQKFXyJfxvHSbkE33c+Z2dxEpZcgPm54nKQ5sv4NB0cPLpVtjVRFSNYuPzw00KH+MrHch6DLLev98i8Yy7SAUAqdH9sHKBOTjj2mZH2XaxJentZGxJNLZP2SCWx5duCdOFEHO5Y9iT1aZY3bh5N5+BL5lVXATzRJ8F5beEBAmeTH21qZUd+OXymGWhOaYNk8GAEKLKsYw9FRbBgckhncz4bdIh47LhGdMlES0yDTyYLMNdMCswseShptGI3Cna/s/a0B90dibDIKfRqj5LI54SRv6LAIOn2lhwrlyyB8cj/MZfvI/zw== X-YMail-OSG: .tr48E0VM1mw62EF1R3QUI0pdELnrMzkT8II.LO1znVTDOOKHGjsYoJ5JM_YOUD 0ZXb7NKC0x.s7NupLuuZjtX454JzAON.EcCmhI3jE50hrLU8jzZobD9mSNABxKwYYgatq8BIaAHr wzyHh4D3Lm2Tpq6SuWRvPJgC99aaDBMYlIWjVEh_ErcLy24mReh_E1mbVD8kxGXr8Ob7c8IazrTs LsL4iJYxWGkC8JSQQhtr6t04d0HkcSG2fhAz4h6MO4GxTUQDim2yf5LOJqX9.vMer3Na15B1L1G6 ADbtJ8Ckf3hv6hgsYbteeLkV1ExFnIPOKkrkaXItNvum5IT4wIkLxHwIrjkWXxNJuPM0eVh8sDXT dIciQTRG6Zloke1KTaJx8Ra2vwOUsGIAPuSrBT98MjGptYe.JIQuqtPUcMQZb8VyZFWPVzKIFqiz B0aqwaajhjI_2bQaglBS_lVdBpl3LbMAqQaJldT2S6j3d6iYAdfzR0BvY3kR.9W7C_THVmnEIRYb H8w5qF9dntyn8tAx2qLin8rQSSwK68iaEADNM.n.4n42a.q.KTdenp9yWEQf1EbzjkymR7cCAz7E T4QA3OSde_ATV0rU3cD9yEFS3O0BvOxZ4ai0U2AUy5mYHTv8oGo1Axkpp3tDpBbNNSRGChJwPAgz EWVf1K5ekdT0bvXIo57pmRvHm0GHg6hFYl8lLoTUyPQCtErHUplv0MjTlATs6pCtSpck9fBITE1r LwmJR8ialQPv2XJSVsWZm7qWXjJ5_McPAcpOK.PSAYN4OjquDPpUQdQ0.zbpf2ur.H1xwVXO6qdC gQ.jNzbFplKZF4J1BiHGa8BvxdXAPDshLxwovF6e6j2GiQdYnUhSvOSJb_4wOHUHaybnSbTrMgLc udtL6i6KIlNkdXniIuZzGRgJCFEgrgMNzkG8ZJoOP5VeJmdo7binGQuuLHvAloMgJuyzgXrN96m_ o8sXnLwAj2CTXWL8au3sN4S769zKmLT8ItzEDyW2fdT_I2sNG6Ln0ATZPLMbCcuR.91KVUgsbnHM d0lig7ZaHqsvuqCG3FJkoYKieO39mFtxeuNiblHjpqHFFBuHubazmucymfVWBdHxTGx5FQwXYVdp a_vGrILJuwrArGArPU4yi6wP2eAIKR.Faj6cwNF.f5jPbsbeE.vdwdNB4pg4UlMpZyxgLR7hj3Sp CVlqavP2.14PSes9h6P7dqoLgTq5hSNMDISy6VnGkLoJDzEKN8jwH6eezeuR6rU7Tzu2zzM75dXO PwgUbdzzOVRfr0rGT6EyRD1OSGmagGinoyu75bSO1EXqamybqqK.iX.EwIiEthWjihN5z4Wszi6n O3OjYeVREXiQsSxCgZR37Vh.9Dfud8gsG5.uYtN5zpInT4hNwOtExOQXDdZWiy0T0lxA_3q5laso wBbCPvPpUuRw5OricCI6.1Z_sfZ1lMwMza5eonbL5ofySiPEdPh3Bh1z_M9tKbkb3DjoSi.QtRVm NXXlHtGwy51rJJlFvo8ZoLH28lPkMEplLVIjlFA4Nyn9psVcHy4z.Ud.txled1UosnhmUAJENAFS Mz41MSHXU6Ymx0vUFIzEZ5DPclO8WrwxCKdxCyGD7BjuFIyufkg_RMqOxkkis8xh7S4LJvTZy6al tbkzl8mudg89.aAIHQRHFrSqtWS.z_2QDVuuX5f.VEla2iziO7GDdXY6NZM84fZ9iTYANEYJzz6Z t.3XV99IX.jN.BlfNshH60shrteRFexHyCfJ5YK2gUEvfyya4_ufma_FXyjbrlinhcegG8s_B_Uf pSrkw3j9sGiCx.dgPSPlHDjEIdhW7rE4avjWUZOUhb8RV_ZH8VU_QzOYjtoCOjGdpzEHagGWGvmM a3jBDqMU.uaQsIpaHzMORJGUEj_EexBslVR5unCsvlF04G33U9eTh2xASNmTJaz3oju9C97qxVKg JzRSOYzSUZEaq2haTZGs6ZWyFk5BGEslyGRoIunH6mzO8zqhPgRqgOOj3RIjwNfzYsor9WqOgdz2 OH3.2d_Ao_WNo3u9.nl6ZEDoDjIOQ1_BhIiwB4QpAWji0oqzpzbFQ.FKadHcUjqD0cZQ2JWEzvvY pdAxrvKwiVyjyjXy2duqirTUQ1BqDXf0gY.Kx2l6E4fuZ.bUVVCwUepSN9qoE8xLvuY3fbKMkE9t oPFgyyDjPpJ2pR.GaXCPle86zG2ksX9mknGsxtmVWajLYdfLeHeCFBBHnEdnbKU8a4FFRt_EvKNX GRn5O4QvHFP6la6qDVBu9MnxGGxygHbHCTCmu3.XkKu.j2UAnQ_z6h5eHh7CFOHkeIRwDIWDyCd8 J3Dw- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 15 Jan 2022 23:25:49 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c33e7568a87eb9e85c832828c25fea4d; Sat, 15 Jan 2022 23:25:48 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: WITH_ASAN= vs. vfork: ASAN can not deal with vfork in a reliable manor, so what to do to avoid vfork fairly generally, including for kyua? Message-Id: Date: Sat, 15 Jan 2022 15:25:45 -0800 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4JbvRp0Z0yz3h0F X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=oDU1D5Pl; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.206 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-0.50 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; SUBJECT_ENDS_QUESTION(1.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.206:from]; MLMMJ_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.206:from]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N ASAN is documented to not be able to deal reliably with vfork use (inaccurate results, result mixing interpretations of the old and new contexts, and so on). [There may be other routines sufficiently analogous to vfork to have the same sorts of issues. I'll write only of vfork explicitly.] It turns out that using SH_DISABLE_VFORK=3D with kyua runs helps avoid a bunch of junk failure ASAN reports that involve /bin/sh using vfork. So I've been recently using the likes of: env SH_DISABLE_VFORK=3D ASAN_OPTIONS=3Ddetect_container_overflow=3D0 \ kyua test -k /usr/tests/Kyuafile in my kyua runs. But that need not cover all the vfork use in the kyua runs --or in general system operation. There is more that could be done. For example . . . contrib/llvm-project/compiler-rt/lib/asan/asan_interceptors.h currently has: #if SANITIZER_LINUX && \ (defined(__arm__) || defined(__aarch64__) || defined(__i386__) || \ defined(__x86_64__) || SANITIZER_RISCV64) # define ASAN_INTERCEPT_VFORK 1 #else # define ASAN_INTERCEPT_VFORK 0 #endif The "# define ASAN_INTERCEPT_VFORK 1" causes interception to use fork for the vfork implementation, instead of an actual vfork. It looks to me like asan_interceptors.h for FreeBSD should also be using: # define ASAN_INTERCEPT_VFORK 1 but it currently is not. There is even the possibility that a WITH_ASAN=3D buildworld could build a world that uses fork behavior for vfork and never does an actual vfork (by behavior). Basically restricting itself to things that fit with ASAN use. I tracked this issue down via a report in a kyua run that referenced: QUOTE ERROR: AddressSanitizer: stack-buffer-underflow on address = 0x7fffffffa580 at pc 0x000801e0f8ed bp 0x7fffffff9bf0 sp 0x7fffffff9be8 WRITE of size 8 at 0x7fffffffa580 thread T0 . . . Address 0x7fffffffa580 is located in stack of thread T0 at offset 0 in = frame #0 0x7fffffffa5ef () This frame has 1 object(s): [32, 288) 'buf' (line 180) HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) END QUOTE The "'buf' (line 180)" turned out to be from the declaration in bin/sh/exec.c 's tryexec : static void tryexec(char *cmd, char **argv, char **envp) { int e, in; ssize_t n; char buf[256]; execve(cmd, argv, envp); e =3D errno; if (e =3D=3D ENOEXEC) { INTOFF; in =3D open(cmd, O_RDONLY | O_NONBLOCK); if (in !=3D -1) { n =3D pread(in, buf, sizeof buf, 0); close(in); if (n > 0 && isbinary(buf, n)) { errno =3D ENOEXEC; return; } } *argv =3D cmd; *--argv =3D __DECONST(char *, _PATH_BSHELL); execve(_PATH_BSHELL, argv, envp); } errno =3D e; } So I could finally see/validate that an example stack-buffer-* report was tied to vfork handling (analyzing other code related to the tryexec use). The report happens well after tryexec did its execve. The information about buf is just old, no longer accurate information, leading to a false report: =3D=3D87961=3D=3DERROR: AddressSanitizer: stack-buffer-underflow on = address 0x7fffffffa580 at pc 0x000801e0f8ed bp 0x7fffffff9bf0 sp = 0x7fffffff9be8 WRITE of size 8 at 0x7fffffffa580 thread T0 #0 0x801e0f8ec in bintime2timespec = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 #1 0x801e0f8ec in __vdso_clock_gettime = /usr/main-src/lib/libc/sys/__vdso_gettimeofday.c:195:2 #2 0x801e0e1a0 in clock_gettime = /usr/main-src/lib/libc/sys/clock_gettime.c:48:11 #3 0x10d54da in clock_gettime = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_common_interceptors.inc:2189:13 #4 0x11234f5 in __sanitizer::MonotonicNanoTime() = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_linux_libcdep.cpp:860:3 #5 0x10ba02c in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::PopulateFreeArray(__sanitizer::AllocatorStats*, unsigned = long, __sanitizer::SizeClassAllocator 64<__asan::AP64<__sanitizer::LocalAddressSpaceView> >::RegionInfo*, = unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_primary64.h:790:45 #6 0x10b9c4b in = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >::GetFromAllocator(__sanitizer::AllocatorStats*, unsigned = long, unsigned int*, unsigned long) /u = sr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitize= r_allocator_primary64.h:220:11 #7 0x10b9955 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Refill(__sanitizer::SizeClassAllocator64LocalCac = he<__sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddres= sSpaceView> > >::PerClass*, = __sanitizer::SizeClassAllocator64<__asan::AP64<__sanitizer::LocalAddressSp= aceView> >*, unsigned lo ng) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:103:9 #8 0x10b9615 in = __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocato= r64<__asan::AP64<__sanitizer::LocalAddressSpaceView> > = >::Allocate(__sanitizer::SizeClassAllocator64<__asa n::AP64<__sanitizer::LocalAddressSpaceView> >*, unsigned long) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/saniti= zer_allocator_local_cache.h:39:11 #9 0x10b9511 in = __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::A= P64<__sanitizer::LocalAddressSpaceView> >, = __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate(__san = itizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<_= _asan::AP64<__sanitizer::LocalAddressSpaceView> > >*, unsigned long, = unsigned long) /usr/main-src/contrib/llvm-project/compile r-rt/lib/sanitizer_common/sanitizer_allocator_combined.h:69:20 #10 0x10b6086 in __asan::Allocator::Allocate(unsigned long, unsigned = long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_a llocator.cpp:537:29 #11 0x10b4818 in __asan::asan_malloc(unsigned long, = __sanitizer::BufferedStackTrace*) = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_allocator.cpp= :980:34 #12 0x110be9b in malloc = /usr/main-src/contrib/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.= cpp:130:10 #13 0x117aca3 in ckmalloc /usr/main-src/bin/sh/memalloc.c:71:6 #14 0x115b1b1 in reprocess /usr/main-src/bin/sh/expand.c:912:9 #15 0x1155163 in evalvar /usr/main-src/bin/sh/expand.c:784:3 #16 0x1155163 in argstr /usr/main-src/bin/sh/expand.c:319:8 #17 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #18 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 #19 0x114705b in evalbackcmd /usr/main-src/bin/sh/eval.c:681:4 #20 0x1151bfc in expbackq /usr/main-src/bin/sh/expand.c:476:2 #21 0x1151bfc in argstr /usr/main-src/bin/sh/expand.c:323:4 #22 0x1151178 in expandarg /usr/main-src/bin/sh/expand.c:241:2 #23 0x11427c8 in evalcommand /usr/main-src/bin/sh/eval.c:857:4 #24 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #25 0x113eb88 in evalstring /usr/main-src/bin/sh/eval.c #26 0x113e9f9 in evalcmd /usr/main-src/bin/sh/eval.c:139:17 #27 0x1145289 in evalcommand /usr/main-src/bin/sh/eval.c:1107:16 #28 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #29 0x113f86b in evaltree /usr/main-src/bin/sh/eval.c:212:4 #30 0x1144d89 in evalcommand /usr/main-src/bin/sh/eval.c:1053:3 #31 0x113eeb7 in evaltree /usr/main-src/bin/sh/eval.c:289:4 #32 0x117a316 in cmdloop /usr/main-src/bin/sh/main.c:228:4 #33 0x1179788 in main /usr/main-src/bin/sh/main.c:175:3 Address 0x7fffffffa580 is located in stack of thread T0 at offset 0 in = frame #0 0x7fffffffa5ef () This frame has 1 object(s): [32, 288) 'buf' (line 180) HINT: this may be a false positive if your program uses some custom = stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-underflow = /usr/obj/BUILDs/main-amd64-nodbg-clang-alt/usr/main-src/amd64.amd64/tmp/us= r/include/sys/time.h:285:14 in bintime2timespec Shadow bytes around the buggy address: 0x4ffffffff460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =3D>0x4ffffffff4b0:[f1]f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4d0: 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 0x4ffffffff4e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x4ffffffff4f0: f1 f1 f1 f1 00 f2 f2 f2 00 f3 f3 f3 00 00 00 00 0x4ffffffff500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07=20 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb =3D=3D87961=3D=3DABORTING =3D=3D=3D Mark Millard marklmi at yahoo.com