<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>188741</bug_id>
          
          <creation_ts>2018-08-20 02:40:51 -0700</creation_ts>
          <short_desc>[JSC] Suppress UBSan warnings for KeywordLookup</short_desc>
          <delta_ts>2020-06-12 20:29:23 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>New Bugs</component>
          <version>WebKit Nightly Build</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>NEW</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          <blocked>196533</blocked>
          <everconfirmed>1</everconfirmed>
          <reporter name="Yusuke Suzuki">ysuzuki</reporter>
          <assigned_to name="Yusuke Suzuki">ysuzuki</assigned_to>
          <cc>benjamin</cc>
    
    <cc>cdumez</cc>
    
    <cc>cmarcelo</cc>
    
    <cc>dbates</cc>
    
    <cc>don.olmstead</cc>
    
    <cc>ews-watchlist</cc>
    
    <cc>fpizlo</cc>
    
    <cc>fujii</cc>
    
    <cc>keith_miller</cc>
    
    <cc>mark.lam</cc>
    
    <cc>mcatanzaro</cc>
    
    <cc>msaboff</cc>
    
    <cc>saagarjha</cc>
    
    <cc>saam</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1451561</commentid>
    <comment_count>0</comment_count>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2018-08-20 02:40:51 -0700</bug_when>
    <thetext>[JSC] Suppress UBSan warnings for KeywordLookup</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1451563</commentid>
    <comment_count>1</comment_count>
      <attachid>347489</attachid>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2018-08-20 02:47:14 -0700</bug_when>
    <thetext>Created attachment 347489
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1453374</commentid>
    <comment_count>2</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2018-08-23 19:46:34 -0700</bug_when>
    <thetext>Can you use WTF::unalignedLoad instead of reinterpret_cast in this case?

There is a code path for CPU(NEEDS_ALIGNED_ACCESS). How about the idea to use the code path if UBSan is enabled?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1453375</commentid>
    <comment_count>3</comment_count>
    <who name="Fujii Hironori">fujii</who>
    <bug_when>2018-08-23 19:47:57 -0700</bug_when>
    <thetext>Don, 

IIUC, we (SIE) want to remove undefined behaviors as much as possible for CFI. Right?

Control Flow Integrity
https://clang.llvm.org/docs/ControlFlowIntegrity.html</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1453474</commentid>
    <comment_count>4</comment_count>
    <who name="Don Olmstead">don.olmstead</who>
    <bug_when>2018-08-24 10:09:38 -0700</bug_when>
    <thetext>(In reply to Fujii Hironori from comment #3)
&gt; Don, 
&gt; 
&gt; IIUC, we (SIE) want to remove undefined behaviors as much as possible for
&gt; CFI. Right?
&gt; 
&gt; Control Flow Integrity
&gt; https://clang.llvm.org/docs/ControlFlowIntegrity.html

For CFI the unaligned loads should not be a problem. Patch as is looks fine I&apos;m just interested in knowing if something like the WTF functions mentioned would be of use here just for reuse purposes.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1523879</commentid>
    <comment_count>5</comment_count>
      <attachid>347489</attachid>
    <who name="Filip Pizlo">fpizlo</who>
    <bug_when>2019-04-03 13:33:02 -0700</bug_when>
    <thetext>Comment on attachment 347489
Patch

I’m not sure we should be splatting these blacklist things - it makes the code uglier.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1523882</commentid>
    <comment_count>6</comment_count>
    <who name="Don Olmstead">don.olmstead</who>
    <bug_when>2019-04-03 13:35:56 -0700</bug_when>
    <thetext>(In reply to Filip Pizlo from comment #5)
&gt; Comment on attachment 347489 [details]
&gt; Patch
&gt; 
&gt; I’m not sure we should be splatting these blacklist things - it makes the
&gt; code uglier.

We can use a blacklist file or annotate the code. The benefit from having it in code is that you can see right away that the code is relying on undefined behavior.

I don&apos;t have a strong opinion either way.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1526773</commentid>
    <comment_count>7</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2019-04-12 09:57:50 -0700</bug_when>
    <thetext>(In reply to Filip Pizlo from comment #5)
&gt; Comment on attachment 347489 [details]
&gt; Patch
&gt; 
&gt; I’m not sure we should be splatting these blacklist things - it makes the
&gt; code uglier.

This looks like really low-cost to me. WebKit already has SUPPRESS_ASAN because we recognize asan is an extremely valuable tool for finding security bugs, and using SUPPRESS_ASAN in a couple odd places is less-invasive than rewriting those places to not trigger asan. (If we don&apos;t rewrite the code, and don&apos;t use SUPPRESS_ASAN, then we simply can&apos;t use asan.)

Now, ubsan is less-valuable than asan, but that&apos;s only because asan is really really good. Making a couple small tweaks to the code like this to please ubsan seems valuable to me, since it will make it much easier to run WebKit under ubsan. This seems much more valuable to me than a blacklist file, since that would require extra work to configure and would reduce the ease of running WebKit under ubsan.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1526782</commentid>
    <comment_count>8</comment_count>
    <who name="Filip Pizlo">fpizlo</who>
    <bug_when>2019-04-12 10:14:12 -0700</bug_when>
    <thetext>(In reply to Michael Catanzaro from comment #7)
&gt; (In reply to Filip Pizlo from comment #5)
&gt; &gt; Comment on attachment 347489 [details]
&gt; &gt; Patch
&gt; &gt; 
&gt; &gt; I’m not sure we should be splatting these blacklist things - it makes the
&gt; &gt; code uglier.
&gt; 
&gt; This looks like really low-cost to me. WebKit already has SUPPRESS_ASAN
&gt; because we recognize asan is an extremely valuable tool for finding security
&gt; bugs, and using SUPPRESS_ASAN in a couple odd places is less-invasive than
&gt; rewriting those places to not trigger asan. (If we don&apos;t rewrite the code,
&gt; and don&apos;t use SUPPRESS_ASAN, then we simply can&apos;t use asan.)

I don’t mind these annotations for asan. I was only talking about ubsan. 

&gt; 
&gt; Now, ubsan is less-valuable than asan, but that&apos;s only because asan is
&gt; really really good. Making a couple small tweaks to the code like this to
&gt; please ubsan seems valuable to me, since it will make it much easier to run
&gt; WebKit under ubsan. This seems much more valuable to me than a blacklist
&gt; file, since that would require extra work to configure and would reduce the
&gt; ease of running WebKit under ubsan.

Ubsan is such a silly concept. The case of reporting bad shift amounts as errors is particularly silly: the only fix for that is to mask the shift amount. If that’s the only fix then we should ask for something that just applies those masks for us everywhere. 

The same argument can be made for most other kinds of UB.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1553513</commentid>
    <comment_count>9</comment_count>
    <who name="Saagar Jha">saagarjha</who>
    <bug_when>2019-07-17 08:33:59 -0700</bug_when>
    <thetext>The code exhibiting undefined behavior that this bug mentions has been rewritten to be standards-compliant in https://bugs.webkit.org/show_bug.cgi?id=199650, so I don&apos;t think we need that part of the changeset anymore. I think that adding annotations is still useful, however: there are lot of places in WebKit that remain noncompliant, and an annotation like this would be useful to mark all the places we haven&apos;t gotten around to fixing yet as well as ensuring that new code remains free of undefined behavior.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1662313</commentid>
    <comment_count>10</comment_count>
      <attachid>347489</attachid>
    <who name="Yusuke Suzuki">ysuzuki</who>
    <bug_when>2020-06-12 20:29:23 -0700</bug_when>
    <thetext>Comment on attachment 347489
Patch

For now, I&apos;m not planning to do this.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>347489</attachid>
            <date>2018-08-20 02:47:14 -0700</date>
            <delta_ts>2020-06-12 20:29:23 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-188741-20180820184714.patch</filename>
            <type>text/plain</type>
            <size>3384</size>
            <attacher name="Yusuke Suzuki">ysuzuki</attacher>
            
              <data encoding="base64">U3VidmVyc2lvbiBSZXZpc2lvbjogMjM1MDI1CmRpZmYgLS1naXQgYS9Tb3VyY2UvSmF2YVNjcmlw
dENvcmUvQ2hhbmdlTG9nIGIvU291cmNlL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCA4
ZjRmMzM4MGI5ZDY4MDgxZjE0YjQ1YTVjYzUzZDNiNzA5ODNmZjkxLi5hNzI5OTkzN2QwNmFmMWU4
NjkyYTJmNzc2NTQ1YThhYjkxMDk1YmZiIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENv
cmUvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEs
MyArMSwxNiBAQAorMjAxOC0wOC0yMCAgWXVzdWtlIFN1enVraSAgPHl1c3VrZXN1enVraUBzbG93
c3RhcnQub3JnPgorCisgICAgICAgIFtKU0NdIFN1cHByZXNzIFVCU2FuIHdhcm5pbmdzIGZvciBL
ZXl3b3JkTG9va3VwCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNn
aT9pZD0xODg3NDEKKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAg
ICAgICBBbm5vdGF0ZSBLZXl3b3JkTG9va3VwIGZ1bmN0aW9uIHdpdGggU1VQUFJFU1NfVUJTQU4g
c2luY2UgaXQgdXRpbGl6ZXMgdW5hbGlnbmVkCisgICAgICAgIGFjY2Vzc2VzIGhlYXZpbHkgZm9y
IHNvbWUgQ1BVcyBzdWNoIGFzIHg4Ni4KKworICAgICAgICAqIEtleXdvcmRMb29rdXBHZW5lcmF0
b3IucHk6CisgICAgICAgIChUcmllLnByaW50QXNDKToKKwogMjAxOC0wOC0xOSAgQ2FybG9zIEdh
cmNpYSBDYW1wb3MgIDxjZ2FyY2lhQGlnYWxpYS5jb20+CiAKICAgICAgICAgW0dMSUJdIEFkZCBB
UEkgdG8gdGhyb3cgZXhjZXB0aW9ucyB1c2luZyBwcmludGYgZm9ybWF0dGVkIHN0cmluZ3MKZGlm
ZiAtLWdpdCBhL1NvdXJjZS9XVEYvQ2hhbmdlTG9nIGIvU291cmNlL1dURi9DaGFuZ2VMb2cKaW5k
ZXggZWFjMTY4NWY3NTQwMGZkMjE1MzViNDM1ZjIyZGE4MjUwMzBlNDViOC4uODVmYWViM2I0MTIy
N2JmMmUyYzE3NjI4NTEyYWJhNzZhMjM2MDk5NSAxMDA2NDQKLS0tIGEvU291cmNlL1dURi9DaGFu
Z2VMb2cKKysrIGIvU291cmNlL1dURi9DaGFuZ2VMb2cKQEAgLTEsMyArMSwxNCBAQAorMjAxOC0w
OC0yMCAgWXVzdWtlIFN1enVraSAgPHl1c3VrZXN1enVraUBzbG93c3RhcnQub3JnPgorCisgICAg
ICAgIFtKU0NdIFN1cHByZXNzIFVCU2FuIHdhcm5pbmdzIGZvciBLZXl3b3JkTG9va3VwCisgICAg
ICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0xODg3NDEKKworICAg
ICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBBZGQgU1VQUFJFU1Nf
VUJTQU4KKworICAgICAgICAqIHd0Zi9Db21waWxlci5oOgorCiAyMDE4LTA4LTE5ICBZdXN1a2Ug
U3V6dWtpICA8eXVzdWtlc3V6dWtpQHNsb3dzdGFydC5vcmc+CiAKICAgICAgICAgW1dURl0gQWRk
IFdURjo6dW5hbGlnbmVkTG9hZCBhbmQgV1RGOjp1bmFsaWduZWRTdG9yZQpkaWZmIC0tZ2l0IGEv
U291cmNlL0phdmFTY3JpcHRDb3JlL0tleXdvcmRMb29rdXBHZW5lcmF0b3IucHkgYi9Tb3VyY2Uv
SmF2YVNjcmlwdENvcmUvS2V5d29yZExvb2t1cEdlbmVyYXRvci5weQppbmRleCBkMTNkYWJhNjFk
MjQ3NThiMGEwNjJhOTY5NWExZTE4MjUwOTRjNDZlLi5hY2M0YTA1M2FiMDJlYTlhYzhhYTRlYWNi
MTUyN2Q3NDg2NzNhMWIwIDEwMDY0NAotLS0gYS9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvS2V5d29y
ZExvb2t1cEdlbmVyYXRvci5weQorKysgYi9Tb3VyY2UvSmF2YVNjcmlwdENvcmUvS2V5d29yZExv
b2t1cEdlbmVyYXRvci5weQpAQCAtMTkwLDcgKzE5MCw3IEBAIGRlZiBwcmludEFzQyhzZWxmKToK
ICAgICAgICAgcHJpbnQoInN0YXRpYyBjb25zdCBpbnQgbWF4VG9rZW5MZW5ndGggPSAlZDsiICUg
KHNlbGYubWF4TGVuZ3RoKCkgKyAxKSkKICAgICAgICAgcHJpbnQoIiIpCiAgICAgICAgIHByaW50
KCJ0ZW1wbGF0ZSA8PiIpCi0gICAgICAgIHByaW50KCJ0ZW1wbGF0ZSA8Ym9vbCBzaG91bGRDcmVh
dGVJZGVudGlmaWVyPiBBTFdBWVNfSU5MSU5FIEpTVG9rZW5UeXBlIExleGVyPFVDaGFyPjo6cGFy
c2VLZXl3b3JkKEpTVG9rZW5EYXRhKiBkYXRhKSIpCisgICAgICAgIHByaW50KCJ0ZW1wbGF0ZSA8
Ym9vbCBzaG91bGRDcmVhdGVJZGVudGlmaWVyPiBTVVBQUkVTU19VQlNBTiBBTFdBWVNfSU5MSU5F
IEpTVG9rZW5UeXBlIExleGVyPFVDaGFyPjo6cGFyc2VLZXl3b3JkKEpTVG9rZW5EYXRhKiBkYXRh
KSIpCiAgICAgICAgIHByaW50KCJ7IikKICAgICAgICAgcHJpbnQoIiAgICBBU1NFUlQobV9jb2Rl
RW5kIC0gbV9jb2RlID49IG1heFRva2VuTGVuZ3RoKTsiKQogICAgICAgICBwcmludCgiIikKQEAg
LTIwMCw3ICsyMDAsNyBAQCBkZWYgcHJpbnRBc0Moc2VsZik6CiAgICAgICAgIHByaW50KCJ9IikK
ICAgICAgICAgcHJpbnQoIiIpCiAgICAgICAgIHByaW50KCJ0ZW1wbGF0ZSA8PiIpCi0gICAgICAg
IHByaW50KCJ0ZW1wbGF0ZSA8Ym9vbCBzaG91bGRDcmVhdGVJZGVudGlmaWVyPiBBTFdBWVNfSU5M
SU5FIEpTVG9rZW5UeXBlIExleGVyPExDaGFyPjo6cGFyc2VLZXl3b3JkKEpTVG9rZW5EYXRhKiBk
YXRhKSIpCisgICAgICAgIHByaW50KCJ0ZW1wbGF0ZSA8Ym9vbCBzaG91bGRDcmVhdGVJZGVudGlm
aWVyPiBTVVBQUkVTU19VQlNBTiBBTFdBWVNfSU5MSU5FIEpTVG9rZW5UeXBlIExleGVyPExDaGFy
Pjo6cGFyc2VLZXl3b3JkKEpTVG9rZW5EYXRhKiBkYXRhKSIpCiAgICAgICAgIHByaW50KCJ7IikK
ICAgICAgICAgcHJpbnQoIiAgICBBU1NFUlQobV9jb2RlRW5kIC0gbV9jb2RlID49IG1heFRva2Vu
TGVuZ3RoKTsiKQogICAgICAgICBwcmludCgiIikKZGlmZiAtLWdpdCBhL1NvdXJjZS9XVEYvd3Rm
L0NvbXBpbGVyLmggYi9Tb3VyY2UvV1RGL3d0Zi9Db21waWxlci5oCmluZGV4IDc5OGMzMDkwYzli
MWMxODU4MGEzYTZiZTZmYWI2NWJkYWNlNmZmYWEuLmVkYWViYWNkZjlmZGY4NzNmZjgzYTExMzk5
NzBkZjY0YjUxN2VkYjcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XVEYvd3RmL0NvbXBpbGVyLmgKKysr
IGIvU291cmNlL1dURi93dGYvQ29tcGlsZXIuaApAQCAtMTU3LDYgKzE1NywxNCBAQAogI2RlZmlu
ZSBTVVBQUkVTU19BU0FOCiAjZW5kaWYKIAorLyogU1VQUFJFU1NfVUJTQU4gKi8KKworI2lmIENP
TVBJTEVSKEdDQ19PUl9DTEFORykKKyNkZWZpbmUgU1VQUFJFU1NfVUJTQU4gX19hdHRyaWJ1dGVf
Xygobm9fc2FuaXRpemUoInVuZGVmaW5lZCIpKSkKKyNlbHNlCisjZGVmaW5lIFNVUFBSRVNTX1VC
U0FOCisjZW5kaWYKKwogLyogPT09PSBDb21waWxlci1pbmRlcGVuZGVudCBtYWNyb3MgZm9yIHZh
cmlvdXMgY29tcGlsZXIgZmVhdHVyZXMsIGluIGFscGhhYmV0aWNhbCBvcmRlciA9PT09ICovCiAK
IC8qIEFMV0FZU19JTkxJTkUgKi8K
</data>

          </attachment>
      

    </bug>

</bugzilla>