[Git][ghc/ghc][wip/ubsan-fixes] 2 commits: rts: fix an unaligned load in nonmoving gc

[Cheng Shao (@TerrorJack)]

Cheng Shao pushed to branch wip/ubsan-fixes at Glasgow Haskell Compiler / GHC


Commits:
a10e1866 by Cheng Shao at 2024-05-27T18:27:04+00:00
rts: fix an unaligned load in nonmoving gc

This patch fixes an unaligned load in nonmoving gc by ensuring the
closure address is properly untagged first before attempting to
prefetch its header. The unaligned load is reported by
UndefinedBehaviorSanitizer:

```
rts/sm/NonMovingMark.c:921:9: runtime error: member access within misaligned address 0x0042005f3a71 for type 'StgClosure' (aka 'struct StgClosure_'), which requires 8 byte alignment
0x0042005f3a71: note: pointer points here
 00 00 00  98 43 13 8e 12 7f 00 00  50 3c 5f 00 42 00 00 00  58 17 b7 92 12 7f 00 00  89 cb 5e 00 42
              ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior rts/sm/NonMovingMark.c:921:9
```

This issue had previously gone unnoticed since it didn't really harm
runtime correctness, the invalid header address directly loaded from a
tagged pointer is only used as prefetch address and will not cause
segfaults. However, it still should be corrected because the prefetch
would be rendered useless by this issue, and untagging only involves a
single bitwise operation without memory access so it's cheap enough to
add.

- - - - -
89489741 by Cheng Shao at 2024-05-27T18:27:56+00:00
rts: use __builtin_offsetof to implement STG_FIELD_OFFSET

This patch fixes the STG_FIELD_OFFSET macro definition by using
__builtin_offsetof, which is what gcc/clang uses to implement offsetof
in standard C. The previous definition that uses NULL pointer involves
subtle undefined behavior in C and thus reported by
UndefinedBehaviorSanitizer as well:

```
rts/Capability.h:243:58: runtime error: member access within null pointer of type 'Capability' (aka 'struct Capability_')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior rts/Capability.h:243:58
```

- - - - -


2 changed files:

- rts/include/Stg.h
- rts/sm/NonMovingMark.c


Changes:

=====================================
rts/include/Stg.h
=====================================
@@ -108,7 +108,7 @@
 
 /* Compute offsets of struct fields
  */
-#define STG_FIELD_OFFSET(s_type, field) ((StgWord)&(((s_type*)0)->field))
+#define STG_FIELD_OFFSET(s_type, field) __builtin_offsetof(s_type, field)
 
 /*
  * 'Portable' inlining:


=====================================
rts/sm/NonMovingMark.c
=====================================
@@ -918,7 +918,7 @@ static MarkQueueEnt markQueuePop (MarkQueue *q)
         // The entry may not be a MARK_CLOSURE but it doesn't matter, our
         // MarkQueueEnt encoding always places the pointer to the object to be
         // marked first.
-        prefetchForRead(&new.mark_closure.p->header.info);
+        prefetchForRead(&(UNTAG_CLOSURE(new.mark_closure.p)->header.info));
 #if !defined(ASSERTS_ENABLED)
         prefetchForRead(Bdescr((StgPtr) new.mark_closure.p));
 #endif



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7f45ee46273880ff5f8f37cd8ba1968c3df45b27...894897411f45b2e9067bff622d3e275e20e9cc04

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7f45ee46273880ff5f8f37cd8ba1968c3df45b27...894897411f45b2e9067bff622d3e275e20e9cc04
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240527/332e6e7d/attachment-0001.html>