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. On Wed, Mar 25, 2020 at 12:07 AM Michael Lippautz <[email protected]> wrote: > 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. > > On Tue, Mar 24, 2020 at 3:03 AM Chris Palmer <[email protected]> wrote: > >> 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. >> >> On Mon, Mar 23, 2020 at 2:17 PM Jeremy Roman <[email protected]> >> wrote: >> >>> On Mon, Mar 23, 2020 at 4:31 PM Dave Tapuska <[email protected]> >>> wrote: >>> >>>> 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. >>>> >>>> On Mon, Mar 23, 2020 at 4:26 PM Chris Palmer <[email protected]> >>>> wrote: >>>> >>>>> On Mon, Mar 23, 2020 at 12:59 PM Jeremy Roman <[email protected]> >>>>> 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? >>>>> >>>> >>> I meant a per-allocation flag, e.g. added to PartitionAllocFlags. >>> >> -- >> -- >> v8-dev mailing list >> [email protected] >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/CAOuvq21ro4xNDBy_6YHN7SOJCO_MMi6ud98NzHqD1dYuA-qa7g%40mail.gmail.com >> <https://groups.google.com/d/msgid/v8-dev/CAOuvq21ro4xNDBy_6YHN7SOJCO_MMi6ud98NzHqD1dYuA-qa7g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- Kentaro Hara, Tokyo, Japan -- -- v8-dev mailing list [email protected] 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CABg10jxiwMPSzp3pjXi4jLHBbfHfjX5T8gKd3k6MFyTUdygNWw%40mail.gmail.com.
