Shipping range analysis assertion nodes in TurboFan

[neilpa...@gmail.com]

Hi all,

I've been recently investigating type confusion vulnerabilities in the TurboFan JIT (such as this and this). I am doing this by creating systems that mutate the V8 graph and add pass-through "assertion" nodes that verify that the actual type of a value at runtime indeed matches the type computed by TurboFan's typer.

One of the systems I have built runs in pipeline.cc and adds a "range checking node" after every inferred range analysis, which verifies that V8's typer system correctly computes ranges in the Typer phase. This is very similar to existing functionality in other JITs such as IonMonkey, which already use this to catch bugs in range analysis that can lead to security vulnerabilities.

I have verified that my system catches artificially introduced errors in range computation, and does not introduce false positives in existing tests. It is accessible through an optional d8 command-line flag, so it can be used in the fuzzer.

I think this range checking would be useful for catching range analysis-related security vulnerabilities in the future, especially given that it's been used in other JITs. I have working code, but before going through the code submission process, I wanted to ask if there was anything to be aware of independent of implementation (such as existing duplicate functionality) that would be reasons not to ship this feature.

(This is my first time contributing to V8, so my apologies if there's a different way of going about this process - thank you in advance!).

Neil

[Georg Neis]

Hi Neil,

this sounds interesting. We have been thinking about such kind of dynamic checks as well as about improving our typer testing, but we haven't started implemented anything so far. I'd be happy to look at your code.

Best,

 Georg

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Georg Neis
Software Engineer

Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.
     
This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[neilpa...@gmail.com]

Hi Georg,

The CL for review is here: https://chromium-review.googlesource.com/c/v8/v8/+/1598267. (I haven't added unit tests, but can do so if you think the approach is correct and doesn't need significant modification.) Let me know if changes should be made or if there's a different process to submit code.

Thanks,

Neil

On Monday, May 6, 2019 at 3:53:51 AM UTC-5, Georg Neis wrote:

Hi Neil,

this sounds interesting. We have been thinking about such kind of dynamic checks as well as about improving our typer testing, but we haven't started implemented anything so far. I'd be happy to look at your code.

Best,

 Georg

From: <neilpa...@gmail.com>
Date: Sun, May 5, 2019 at 10:25 PM
To: v8-dev

Hi all,

I've been recently investigating type confusion vulnerabilities in the TurboFan JIT (such as this and this). I am doing this by creating systems that mutate the V8 graph and add pass-through "assertion" nodes that verify that the actual type of a value at runtime indeed matches the type computed by TurboFan's typer.

One of the systems I have built runs in pipeline.cc and adds a "range checking node" after every inferred range analysis, which verifies that V8's typer system correctly computes ranges in the Typer phase. This is very similar to existing functionality in other JITs such as IonMonkey, which already use this to catch bugs in range analysis that can lead to security vulnerabilities.

I have verified that my system catches artificially introduced errors in range computation, and does not introduce false positives in existing tests. It is accessible through an optional d8 command-line flag, so it can be used in the fuzzer.

I think this range checking would be useful for catching range analysis-related security vulnerabilities in the future, especially given that it's been used in other JITs. I have working code, but before going through the code submission process, I wanted to ask if there was anything to be aware of independent of implementation (such as existing duplicate functionality) that would be reasons not to ship this feature.

(This is my first time contributing to V8, so my apologies if there's a different way of going about this process - thank you in advance!).

Neil

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Neil Patil]

Friendly bump - has anyone gotten a chance to take a look yet?

[Georg Neis]

Friendly bump - has anyone gotten a chance to take a look yet?

Only a glance so far but it's on my list.

To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/82381946-369d-4d23-b139-af6aec8c5785%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.