From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 0569ECA6E91; Thu, 4 Jul 2024 10:58:44 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 0569ECA6E91 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1720079924; bh=YG5t+0Ag4XAEk4nNbufjRtRYdnZGL/+11Lk9kJbxthA=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=jQ0c0gG3UK5sixLppjMlFm3Df+dOLmCaEUSaZBu7/Kqs91EQyzyHC2Rw9UySBnu08 fglRqM68x+A1rIXtxngb7h1QGe6C/FWWgTuS1YE8g6zBnLRiZN1FPuK94rwie/QBbN oqVuGx0iwxpnbYFW35I4k+EMe2JW1M6B9H+8ILQ4= Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [95.163.41.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id AA862CA6E90 for ; Thu, 4 Jul 2024 10:58:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org AA862CA6E90 Received: by smtp57.i.mail.ru with esmtpa (envelope-from ) id 1sPHMW-00000006vZt-2Ugz; Thu, 04 Jul 2024 10:58:41 +0300 Content-Type: multipart/alternative; boundary="------------Po0qT9sv7RSFtPEXA8d83wzl" Message-ID: <13a5ffa5-c7b4-4476-8969-5dd5c9fadf50@tarantool.org> Date: Thu, 4 Jul 2024 10:58:40 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: Sergey Kaplun , Maxim Kokryashkin Cc: tarantool-patches@dev.tarantool.org References: <78410e4aed436f123711eeb89d4a4146949b4eef.1719329795.git.skaplun@tarantool.org> In-Reply-To: <78410e4aed436f123711eeb89d4a4146949b4eef.1719329795.git.skaplun@tarantool.org> X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: B8F34718100C35BD X-77F55803: 4F1203BC0FB41BD9E6DEAB84015E6B495B5195A9BF6C5A1367FAC0B16AD32565182A05F5380850404D315D3164EDAA4F2EB5D77EF37489D1BB1357BB2E4666AE1AEB3D823B9F9F3AE1BDF786614B4017 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7FCFCB92DA8654BB0EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637C1CDCB5E4A85220F8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D85EFB93F79D58A041D4C8A1A715320BCE70EDC88FC484B92ACC7F00164DA146DAFE8445B8C89999728AA50765F79006370BDB19F53EE528DD389733CBF5DBD5E9C8A9BA7A39EFB766F5D81C698A659EA7CC7F00164DA146DA9985D098DBDEAEC886A7C529F68B8E5CF6B57BC7E6449061A352F6E88A58FB86F5D81C698A659EA73AA81AA40904B5D9A18204E546F3947C6089696B24BB1D19C0837EA9F3D197644AD6D5ED66289B523666184CF4C3C14F6136E347CC761E07725E5C173C3A84C382354B272D6C28B2BA3038C0950A5D36B5C8C57E37DE458B330BD67F2E7D9AF16D1867E19FE14079C09775C1D3CA48CFED8438A78DFE0A9E1DD303D21008E298D5E8D9A59859A8B6957A4DEDD2346B4275ECD9A6C639B01B78DA827A17800CE793E91FE0051307A9731C566533BA786AA5CC5B56E945C8DA X-C1DE0DAB: 0D63561A33F958A517BB692F2AE5D8EB5002B1117B3ED69690826EE28B3AC939F5FEB6EB1EB183FD823CB91A9FED034534781492E4B8EEADB30A456A8F293845BDAD6C7F3747799A X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF3FED46C3ACD6F73ED3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF9647A82147823A9B2B2D6DF45430F90112E78FFEB1A97DBE10648DC3E0EAD697C419EA6F1489DB16CABF58F1CDB0D7D19C10742B36C0A0C7F99050A94690D7183C3330B772EACA275F4332CA8FE04980913E6812662D5F2AB9AF64DB4688768036DF5FE9C0001AF333F2C28C22F508233FCF178C6DD14203 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj2Rj/U0IvFapxBozcAsUnEQ== X-Mailru-Sender: 520A125C2F17F0B1E52FEF5D219D614003D2B03FCDBE44A1ADC900E633CA29F73DC2D496FB0084EF0152A3D17938EB451EB5A0BCEC6A560B3DDE9B364B0DF289BE2DA36745F2EEB5CEBA01FB949A1F1EEAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 1/2] Prevent sanitizer warning in snap_restoredata(). X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Sergey Bronnikov via Tarantool-patches Reply-To: Sergey Bronnikov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" This is a multi-part message in MIME format. --------------Po0qT9sv7RSFtPEXA8d83wzl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Sergey, thanks for the patch! Please add a message "Also, it removes all related UBSAN suppressions, since they are fixed." to commit message, like you did for the second patch. LGTM On 25.06.2024 18:54, Sergey Kaplun wrote: > From: Mike Pall > > Thanks to Sergey Kaplun. > > (cherry picked from commit 4a22050df9e76a28ef904382e4b4c69578973cd5) > > When saving FPR registers during while from a trace and restoring > data from a snapshot, UB sanitizer produces the following warning: > | lj_snap.c:804:32: runtime error: index 23 out of bounds for type 'intptr_t [16]' > > due to indexing `ex->gpr` with a fpr register, whose number is >= > `RID_MAX_GPR`. The situation itself is harmless since this is read from > `spill[256]` array and is rewritten in the next if branch. > > This patch fixes the out-of-bounds access to read from `ex->gpr` only > conditionally. > > Sergey Kaplun: > * added the description and the test for the problem > > Part of tarantool/tarantool#9924 > Relates to tarantool/tarantool#8473 > --- > src/lj_snap.c | 13 +++------ > ...93-out-of-bounds-snap-restoredata.test.lua | 28 +++++++++++++++++++ > 2 files changed, 32 insertions(+), 9 deletions(-) > create mode 100644 test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua > > diff --git a/src/lj_snap.c b/src/lj_snap.c > index 7dc4fe35..8a33dc22 100644 > --- a/src/lj_snap.c > +++ b/src/lj_snap.c > @@ -756,13 +756,6 @@ static void snap_restoreval(jit_State *J, GCtrace *T, ExitState *ex, > } > > #if LJ_HASFFI > -# if LUAJIT_USE_UBSAN > -/* Seehttps://github.com/LuaJIT/LuaJIT/issues/1193. */ > -static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex, > - SnapNo snapno, BloomFilter rfilt, > - IRRef ref, void *dst, CTSize sz) > - __attribute__((no_sanitize("bounds"))); > -# endif > /* Restore raw data from the trace exit state. */ > static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex, > SnapNo snapno, BloomFilter rfilt, > @@ -801,7 +794,6 @@ static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex, > *(lua_Number *)dst = (lua_Number)*(int32_t *)dst; > return; > } > - src = (int32_t *)&ex->gpr[r-RID_MIN_GPR]; > #if !LJ_SOFTFP > if (r >= RID_MAX_GPR) { > src = (int32_t *)&ex->fpr[r-RID_MIN_FPR]; > @@ -815,7 +807,10 @@ static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex, > #endif > } else > #endif > - if (LJ_64 && LJ_BE && sz == 4) src++; > + { > + src = (int32_t *)&ex->gpr[r-RID_MIN_GPR]; > + if (LJ_64 && LJ_BE && sz == 4) src++; > + } > } > } > lj_assertJ(sz == 1 || sz == 2 || sz == 4 || sz == 8, > diff --git a/test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua b/test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua > new file mode 100644 > index 00000000..6c5fc3f6 > --- /dev/null > +++ b/test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua > @@ -0,0 +1,28 @@ > +local tap = require('tap') > + > +-- Test file to demonstrate LuaJIT's out-of-bounds access during > +-- the saving of registers content in `snap_restoredata()`. > +-- See also:https://github.com/LuaJIT/LuaJIT/issues/1193. > + > +local test = tap.test('lj-1193-out-of-bounds-snap-restoredata'):skipcond({ > + ['Test requires JIT enabled'] = not jit.status(), > +}) > + > +local ffi = require('ffi') > + > +test:plan(1) > + > +local double_type = ffi.typeof('double') > + > +jit.opt.start('hotloop=1') > +local x = 1LL > +for _ = 1, 4 do > + -- `x` is saved in the fpr register and will be restored in the > + -- `ex->fpr` during exit from the snapshot. But out-of-bounds > + -- access is happening due to indexing `ex->gpr` occasionally. > + x = double_type(x + 1) > +end > + > +test:ok(true, 'no out-of-bounds failure') > + > +test:done(true) --------------Po0qT9sv7RSFtPEXA8d83wzl Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi, Sergey,

thanks for the patch!

Please add a message "Also, it removes all related UBSAN suppressions, since they are fixed."

to commit message, like you did for the second patch.


LGTM

On 25.06.2024 18:54, Sergey Kaplun wrote:
From: Mike Pall <mike>

Thanks to Sergey Kaplun.

(cherry picked from commit 4a22050df9e76a28ef904382e4b4c69578973cd5)

When saving FPR registers during while from a trace and restoring
data from a snapshot, UB sanitizer produces the following warning:
| lj_snap.c:804:32: runtime error: index 23 out of bounds for type 'intptr_t [16]'

due to indexing `ex->gpr` with a fpr register, whose number is >=
`RID_MAX_GPR`. The situation itself is harmless since this is read from
`spill[256]` array and is rewritten in the next if branch.

This patch fixes the out-of-bounds access to read from `ex->gpr` only
conditionally.

Sergey Kaplun:
* added the description and the test for the problem

Part of tarantool/tarantool#9924
Relates to tarantool/tarantool#8473
---
 src/lj_snap.c                                 | 13 +++------
 ...93-out-of-bounds-snap-restoredata.test.lua | 28 +++++++++++++++++++
 2 files changed, 32 insertions(+), 9 deletions(-)
 create mode 100644 test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua

diff --git a/src/lj_snap.c b/src/lj_snap.c
index 7dc4fe35..8a33dc22 100644
--- a/src/lj_snap.c
+++ b/src/lj_snap.c
@@ -756,13 +756,6 @@ static void snap_restoreval(jit_State *J, GCtrace *T, ExitState *ex,
 }
 
 #if LJ_HASFFI
-# if LUAJIT_USE_UBSAN
-/* See https://github.com/LuaJIT/LuaJIT/issues/1193. */
-static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex,
-			     SnapNo snapno, BloomFilter rfilt,
-			     IRRef ref, void *dst, CTSize sz)
-  __attribute__((no_sanitize("bounds")));
-# endif
 /* Restore raw data from the trace exit state. */
 static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex,
 			     SnapNo snapno, BloomFilter rfilt,
@@ -801,7 +794,6 @@ static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex,
 	*(lua_Number *)dst = (lua_Number)*(int32_t *)dst;
 	return;
       }
-      src = (int32_t *)&ex->gpr[r-RID_MIN_GPR];
 #if !LJ_SOFTFP
       if (r >= RID_MAX_GPR) {
 	src = (int32_t *)&ex->fpr[r-RID_MIN_FPR];
@@ -815,7 +807,10 @@ static void snap_restoredata(jit_State *J, GCtrace *T, ExitState *ex,
 #endif
       } else
 #endif
-      if (LJ_64 && LJ_BE && sz == 4) src++;
+      {
+	src = (int32_t *)&ex->gpr[r-RID_MIN_GPR];
+	if (LJ_64 && LJ_BE && sz == 4) src++;
+      }
     }
   }
   lj_assertJ(sz == 1 || sz == 2 || sz == 4 || sz == 8,
diff --git a/test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua b/test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua
new file mode 100644
index 00000000..6c5fc3f6
--- /dev/null
+++ b/test/tarantool-tests/lj-1193-out-of-bounds-snap-restoredata.test.lua
@@ -0,0 +1,28 @@
+local tap = require('tap')
+
+-- Test file to demonstrate LuaJIT's out-of-bounds access during
+-- the saving of registers content in `snap_restoredata()`.
+-- See also: https://github.com/LuaJIT/LuaJIT/issues/1193.
+
+local test = tap.test('lj-1193-out-of-bounds-snap-restoredata'):skipcond({
+  ['Test requires JIT enabled'] = not jit.status(),
+})
+
+local ffi = require('ffi')
+
+test:plan(1)
+
+local double_type = ffi.typeof('double')
+
+jit.opt.start('hotloop=1')
+local x = 1LL
+for _ = 1, 4 do
+  -- `x` is saved in the fpr register and will be restored in the
+  -- `ex->fpr` during exit from the snapshot. But out-of-bounds
+  -- access is happening due to indexing `ex->gpr` occasionally.
+  x = double_type(x + 1)
+end
+
+test:ok(true, 'no out-of-bounds failure')
+
+test:done(true)
--------------Po0qT9sv7RSFtPEXA8d83wzl--