Implications of hw discovery

[jlb6740]

I was having a discussion @arunetm and it was brought up that issues around discovery would be an important solve as relaxed-simd progressed. Obviously the wasm virtual machine needs to know the capabilities of the hardware it is proxying and so there is that aspect of discovery, but w.r.t. the relaxed simd proposal itself, is there an intent of providing the app developer tools for discovery? Is there an intent of having something to say about discovery that an application developer would be expected to leverage in the code they write? @ngzhian

[Maratyszcza]

In my opinion, Relaxed SIMD should NOT provide mechanisms for hardware discovery, as such mechanisms would simplify fingerprinting. Some of the instruction proposals for Relaxed SIMD may inadvertently hint details about the host processor, and thus instruction proposals should discuss this aspect to avoid blindly increasing fingerprinting surface.

[jlb6740]

Interesting, I did not think about a potential issue of a security risk here. It is still unclear to me though the implications of this proposal providing discovery support .. what does this support look like? @Maratyszcza Can you elaborate on the security risk? Are you speaking about something leaked through some side channel at runtime?

[Maratyszcza]

Fingerprinting is not a security risk, but it has privacy implications. In short, revealing details about the processor makes it possible to track users across websites. Thus, we'd like to limit the details we reveal as much as practical.

[penzn]

Whether fingerprinting can be avoided entirely depends on how deterministic the behavior is - it might be possible to construct tests which would be able to at least distinguish between major classes of hardware.

[arunetm]

I suggest fingerprinting concerns should not prevent useful feature inclusion here. Being a performance extension of a performance feature, it helps if relaxed simd can prioritize perf benefits while doing the best to avoid need for feature detection. Its definitely ideal to prevent fingerprinting, but features like simd itself arguably makes fingerprinting easier.

[ngzhian]

We often need to balance privacy and performance, even with SIMD proposal, it can be possible use timing differences to detect underlying hardware (and it is also already possible with existing Web APIs, though I don't know exactly how.)

When we requested for Chrome's Privacy review, they decided that SIMD did not introduce new fingerprinting surfaces. I think this will be a good standard to stick to.

The tricky bit is how we determine if instructions introduces new fingerprinting surfaces. @dtig reached out to some people working on privacy and security in Chrome to get their early involvement in this process. So we will get some expert help along the way.

As @Maratyszcza mentioned, I think one way that we can do our due diligence is to have a template for new instructions suggestion, to describe fingerprinting surfaces for the new instructions. E.g. for reciprocal instructions, it is possible to drill down to specific processor models.

[Maratyszcza]

@ngzhian In my experience, fingerprinting reciprocal instructions doesn't distinguish individual processor models, but would allow to distinguish Intel processors from AMD processors.

[ngzhian]

but would allow to distinguish Intel processors from AMD processors.

Ah, thank you for correcting me :) I will work on getting a template of some sorts for proposing new instructions, which should encourage authors to think about this more.

[jlb6740]

Showing that something could be theoretically fingerprintable is one thing, but having it be a practical concern I think is a different and separate question. There are so many explicit and covert ways that devices already are or can be fingerprinted, my initial thought is that the concern could stifle a feature unnecessarily. It's a very good question though and as suggested, looking a precedent that has already thought about the problem is a good idea.

[jlb6740]

The implications of discovery though imply that there is some understanding here amongst us of what that would look like for relaxed-simd. Is what that really looks like understood here or is it just implied? Assuming it is being proposed that relaxed-simd would give the developer some API or explicit means to discover features of the hardware, what does that look like if you are writing in C for example and why would that be offered to the developer? As long as you have an unambiguous definition of what the relaxed simd instruction guarantees as a minimum the VM can do the rest, no? As an analogy, say code is written in some high level language like C where x86, wasm, aarch64, etc are all just potential targets but it is written in a way that a compiler can take advantage of avx512. Say I grab that code (maybe I am not the developer) and I want to take advantage of some auto-vectorization to avx512 provided by the compiler so I use a flag to target that while compiling. In doing so neither I nor the developer were given tools for discovery. If there is an attempt by someone to run that binary on a non-compatible machine (x86 machine without avx, wasm vm, or aarch64 machine) it simply doesn't run. Why would not that same model be used here for relaxed simd?

[Maratyszcza]

Assuming it is being proposed that relaxed-simd would give the developer some API or explicit means to discover features of the hardware

There is no plan to provide explicit API to discover hardware features. Developers might implicitly test for hardware features, though, e.g. by checking the output of Quasi-FMA for inputs where multiply-add and FMA produce different results.

If there is an attempt by someone to run that binary on a non-compatible machine (x86 machine without avx, wasm vm, or aarch64 machine) it simply doesn't run

This is beyond the scope of the SIMD (and by extension the Relaxed SIMD) proposal. Like with Fixed-width SIMD proposal, we plan to add only instructions which can be implemented across all practical architectures with SIMD (i.e. x86/x86-64, ARM with NEON, ARM64, and POWER as of today). In Relaxed SIMD we don't require the instructions to produce exactly the same result across all architectures, but expect that there are important use-cases which can be implemented in architecture-agnostic way using the relaxed guarantees of the Relaxed SIMD instructions.

[jlb6740]

@Maratyszcza I see, thanks. So nothing explicit to help out the developer would be provided to them. The privacy concern is born from the fact that developers could mine for details about hardware capabilities which in turn could be used to pinpoint/fingerprint a specific machine. The impression that it was more than this prompted the initial question, so that's good. The ability of an app to do discovery sounds inevitable when the result of a computation is tied to specific hardware. If so I guess the question then is how does relaxed SIMD properly define lines for what features are acceptable to be able to be discovered through these covert means.

[Maratyszcza]

If so I guess the question then is how does relaxed SIMD properly define lines for what features are acceptable to be able to discovery through these covert means.

I expect that for most instructions the only revealed information would be architecture, i.e. x86 vs ARM/ARM64. It is already possible to distinguish x86 vs ARM in WebAssembly (even without SIMD), thus such instructions wouldn't expose any additional fingerprinting surface.

[ngzhian]

If so I guess the question then is how does relaxed SIMD properly define lines for what features are acceptable to be able to discover through these covert means.

I think if an instruction behaves differently on x86 v.s. ARM/ARM64, then it's okay to be included, because it exposes nothing new.

In the more general case, we probably have to look at instructions case-by-case. In a new issue template we have, we specifically ask for

"How does behavior differ across processors? What new fingerprinting surfaces will be exposed?"

to encourage thought and discussion on the privacy implications.

With the experts gathered in this group, as well as people who are concerned about users privacy, I am confident we will be able to standardize a set of instructions that sacrifice neither performance nor privacy.

[rowan-m]

@Maratyszcza what's the current mechanism that allows distinguishing x86 vs ARM in Wasm?

[Maratyszcza]

@rowan-m See https://github.com/google/XNNPACK/blob/bbf51825bc2b96f691121611e8d1d262f76b8010/src/init.c#L73-L78

[penzn]

@rowan-m See https://github.com/google/XNNPACK/blob/bbf51825bc2b96f691121611e8d1d262f76b8010/src/init.c#L73-L78

@Maratyszcza, is this something you have in mind for this proposal as well? For example, relaxed swizzle can be used in one or the other possible way if the platform is known.