Torque: Aligning Members

85 views
Skip to first unread message

Martin Schwarzl

unread,
Jan 24, 2024, 12:22:18 PM1/24/24
to v8-dev
Hi, 

I was wondering if there is a primitive to align the memory representation in torque 
similar to alignas in C++.

To provide more context I'd like to align the JSArrayBuffers members
raw_byte_length, raw_max_byte_length and backing_store to be in the same cache line.

Leszek Swirski

unread,
Jan 24, 2024, 12:45:05 PM1/24/24
to v8-...@googlegroups.com
Hi,

No, the V8 heap allocation doesn't currently support custom alignment. Are you seeing these be in different cache lines a lot? I could imagine that being a problem for a lot of objects if it's a performance issue.

- Leszek

--
--
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/82f8624c-9b77-49e2-a04d-0c92a1a60206n%40googlegroups.com.
Message has been deleted

Leszek Swirski

unread,
Jan 25, 2024, 12:30:45 PM1/25/24
to v8-...@googlegroups.com, sa...@chromium.org

There's not really any fully supported mechanism for this at all at the moment; there's some logic for alignment of HeapNumbers so that their double values stay aligned, so you can look for "AllocationAlignment" in the heap directory (and the HeapObject::RequiredAlignment method), but at the moment this isn't used and I think is broken if you allocate from optimised code. Also keep in mind that allocation has to be preserved when the GC moves objects, not just during allocation.

Note that our security model doesn't really try to be robust against Spectre at all (we rely on site isolation in Chrome to provide process-level memory safety), and especially not for Spectre attacks that are limited to reading within the V8 sandbox (which is not considered sensitive). Is this for a multi-tenant Isolate or something like that?

- Leszek

On Thu, Jan 25, 2024 at 3:50 PM 'Martin Schwarzl' via v8-dev <v8-...@googlegroups.com> wrote:
Thank you for the response! 

It's more a security consideration w.r.t Spectre attacks (https://github.com/google/security-research-pocs/blob/master/spectre.js/leaky.page/templates/spectre_worker.js#L135).

Is there an alternative way of aligning it, maybe after object generation?
It feels like I am maybe missing where in compilation process I could influence the alignment.

Martin Schwarzl

unread,
Jan 25, 2024, 1:01:15 PM1/25/24
to v8-...@googlegroups.com, sa...@chromium.org
There's not really any fully supported mechanism for this at all at the moment; there's some logic for alignment of HeapNumbers so that their double values stay aligned, so you can look for "AllocationAlignment" in the heap directory (and the HeapObject::RequiredAlignment method), but at the moment this isn't used and I think is broken if you allocate from optimised code. Also keep in mind that allocation has to be preserved when the GC moves objects, not just during allocation.
Thank you very much for the answer. 
I see that this is a more difficult problem than expected.

 Is this for a multi-tenant Isolate or something like that?
Yes exactly, we have that multi-tenant scenario and therefore I am currently enumerating 
some possibilities to make exploitation harder. 

You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/OLXPyZEsntk/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAGRskv-Ucfk_iTD4O2_WHzVyzszL1AqKYFYWN44tUFcmK%3DsQdw%40mail.gmail.com.

Martin Schwarzl

unread,
Jan 30, 2024, 7:09:18 AM1/30/24
to Samuel Groß, v8-...@googlegroups.com, sa...@chromium.org
Hi,

Thanks for the response Samuel!

Totally agree that there are other ways of crafting gadgets.

We are currently working on getting the V8 sandbox up and running in our infrastructure.
I can also confirm that it prevents attackers from leveraging ArrayBuffer to get a 64-bit read primitive. 

Moreover, we are also working on isolating secrets from processes running V8 isolates.
Not only from the Spectre point of view but also to reduce the leakage potential of a V8 zero day.

On the short term, we are looking for ways to make publicly known primitives harder to exploit respectively detect exploitation, and, therefore, look a bit into that direction as well.

-Martin


On 26.01.2024, at 13:27, Samuel Groß <sa...@google.com> wrote:

Hi!

Yeah from the V8 security PoV, we assume that an attacker can already read all memory in the process, and there is no effort to prevent that. In particular, the V8 sandbox also explicitly assumes this attacker model.

That said, the V8 sandbox probably and mostly by accident already makes reading out-of-sandbox memory through something like Spectre a bit harder, e.g. ArrayBuffers can no longer be used for that purpose. So that might be something to look into: can the sandbox be extended to defend against speculative reads. I assume it will be hard though: what happens once you misspeculate a branch for example? Probably at that point all bets are off. Also it wouldn't affect any embedder code etc. This would also assume that you have one sandbox per tenant. And finally, I think it'd always be a "best-effort" thing: we wouldn't want to make preventing reads a goal of the sandbox, and so may also not want to take patches in that regard if they have other side effects.

Cheers!
Samuel
Reply all
Reply to author
Forward
0 new messages