Re: An update on WTF::ArrayBuffer

[Ulan Degenbaev]

+v8-dev: fyi

On Fri, Mar 20, 2020 at 3:57 PM Andreas Haas <ah...@chromium.org> wrote:

Hi!

Please take a look at this document for an update on WTF::ArrayBuffer after a refactoring in V8 and Blink in the last month. Fear not, all changes landed before the Chrome code freeze.

Cheers, Andreas, Dominik, and Ulan  

[Kentaro Hara]

This is a massive simplification, thank you very much for working on this! You removed wtf/typed_arrays/ entirely :)

I'm so happy to review CLs that remove a lot of code :D

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABNJt2KuxLfKRd85275jkFZ5OMtim6FH5ZR7jSTCqpFRSTDVZQ%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Dave Tapuska]

Yes this is great. It seems the allocations are still going through partition alloc. Are there plans to remove this dependence on partition alloc or are there plans for partition alloc to support > 2GB +1 page allocations?

dave.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jyB6iNEVVBYs_ck44Mgan_Wkmz7CL7NeH%3Dego0E%2BA__kA%40mail.gmail.com.

[Andreas Haas]

+jkum...@chromium.org is writing on a design doc about bigger allocations. As far as I know with WebAssembly it is already possible to create bigger ArrayBuffers. With JavaScript it is not possible. It is not clear if and how we would want to deal with this inconsistency. The document should provide more details and start that discussion.

Cheers, Andreas

[Chris Palmer]

I'm on the fence about Partition Alloc's 2 GiB limit. We (Chrome Platform Security) have been lifting memory limits right and left as requirements dictate, and this may be another case of that. We had hoped to use the limits as a form of exploit mitigation/bug detection; for example, a single allocation > 2 GiB was deemed more likely to be the result of int32_t integer overflow (or exploit in progress) than a serious request for that much memory. But perhaps that is no longer true, in a modern JavaScript landscape.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAELSTvfnW%2BieD14EGHn5G4UcgAcAoOPWriMsnazPm%2B675wE%3DXA%40mail.gmail.com.

[Jeremy Roman]

[replacing "+jkummerow@" with "jkummerow@"]

Congrats on ladning this!

On Fri, Mar 20, 2020 at 2:29 PM Chris Palmer <pal...@chromium.org> wrote:

I'm on the fence about Partition Alloc's 2 GiB limit. We (Chrome Platform Security) have been lifting memory limits right and left as requirements dictate, and this may be another case of that. We had hoped to use the limits as a form of exploit mitigation/bug detection; for example, a single allocation > 2 GiB was deemed more likely to be the result of int32_t integer overflow (or exploit in progress) than a serious request for that much memory. But perhaps that is no longer true, in a modern JavaScript landscape.

Couldn't this be preserved with an allocation flag that permits large allocations or similar, if you feel that this was a valuable protection?

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAOuvq20w%2B-Zjd7zUO3akGLCAK5UsVb2evUhyOCKbNuux3Ryy6g%40mail.gmail.com.

[Chris Palmer]

On Mon, Mar 23, 2020 at 12:59 PM Jeremy Roman <jbr...@chromium.org> wrote:

I'm on the fence about Partition Alloc's 2 GiB limit. We (Chrome Platform Security) have been lifting memory limits right and left as requirements dictate, and this may be another case of that. We had hoped to use the limits as a form of exploit mitigation/bug detection; for example, a single allocation > 2 GiB was deemed more likely to be the result of int32_t integer overflow (or exploit in progress) than a serious request for that much memory. But perhaps that is no longer true, in a modern JavaScript landscape.

Couldn't this be preserved with an allocation flag that permits large allocations or similar, if you feel that this was a valuable protection?

Would it be possible to not set the flag in some renderer processes? Or would we end up needing to enable it essentially everywhere?

[Dave Tapuska]

Wouldn't it be possible to set it per partition? All of these allocations currently come from the ArrayBuffer partition.

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/platform/wtf/allocator/partitions.cc;l=52;drc=ee4cff87f02e46e1fbbdaef0aa123e05761b35e8;bpv=1;bpt=1?originalUrl=https:%2F%2Fcs.chromium.org%2F

dave.

[Jeremy Roman]

I meant a per-allocation flag, e.g. added to PartitionAllocFlags. 

[Chris Palmer]

Whether per allocation or per partition, it's pretty close to allowing it completely (in which case we might as well do that). The process and its address space are the real security boundary, and an attacker who wants to abuse these large allocations in part of their attack sequence will be able to as long as the capability is in the process and accessible via the web platform.

[Michael Lippautz]

Thanks all for pushing this through! I remember spending quite some time making up those object graphs in my head :)

As for allocation limits: IIRC, the new architectures that we shipped in the past required adjusting virtual limits left and right -- that's on us. The requests for adjusting the actual limits (committed in general, or single allocation) are usually forwarded from users when they encounter those limits on their apps in the wild in one way or another.

--
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAOuvq21ro4xNDBy_6YHN7SOJCO_MMi6ud98NzHqD1dYuA-qa7g%40mail.gmail.com.

[Kentaro Hara]

BTW I'm also supportive of the direction of moving ArrayBuffers from PartitionAlloc to V8's allocator.

As far as I understand, there's no strong reason we have to allocate the backings in PartitionAlloc. My understanding (correct me if I'm wrong) is that we are just using PartitionAlloc because ArrayBuffers were standardized on the DOM side in the original spec.

[Chris Palmer]

Much moreso than the 2 GiB limit, which I can imagine lifting, separating different types of memory is important. I want to make sure that large arbitrary-contents allocations (ArrayBuffers, strings, et c.) cannot be easily laid over recently-freed memory. That's a key UAF exploitation technique, and a key value that Partition Alloc provides. Especially when we allow large/huge arbitrary-contents allocations, it helps attackers work around ASLR just that much more, so the separation becomes more important.

(Keep in mind also that in an MTE world, we'll want our allocators to tag different types of memory with different tags. (We'll probably do this by selecting random tags per allocation, but something a bit more sophisticated might turn out to be necessary.) Just something to think about for the future.)

You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jxiwMPSzp3pjXi4jLHBbfHfjX5T8gKd3k6MFyTUdygNWw%40mail.gmail.com.