Kernels assume dim <= kTensorDimensionLimit

[dbort]

🐛 Describe the bug

While reviewing #7943 it surfaced that a lot of kernels and kernel utilities assume that tensors will never have more than kTensorDimensionLimit, or in some cases defining their own values for kTensorDimensionLimit and not checking that the tensor dimensions are actually smaller than that value.

Nothing in the runtime today puts a limit on the number of dimensions of a tensor. It would be legal to construct a PTE file that contains a tensor with kTensorDimensionLimit + 1 dimensions, and it would be legal for a model to define an input with kTensorDimensionLimit + dimensions.

And even if the model's tensors fit within the assumed size, a PTE file could become corrupted in a way that increases a tensor's dimensions.

If a kernel or backend encountered a tensor with an unexpectedly-large number of dimensions, they may overrun stack-resident buffers, causing subtle or not-so-subtle problems, corruption, and crashes. It's also a potential security attack vector.

Auditing existing code is one step, followed by adding regression tests to ensure that fixes stay fixed.

Fuzzing is another important tool, along with tools like @manuelcandales's kernel testing tool. These would help us uncover unknown assumptions, and help us run regression tests against the code.

cc: @swolchok

Versions

ExecuTorch 0.5.0

cc @larryliu0820 @manuelcandales

[larryliu0820]

We should probably error out during emitter/deserialization, if the PTE contains a tensor with its rank larger than the limit.

[dbort]

We should probably error out during emitter/deserialization, if the PTE contains a tensor with its rank larger than the limit.

I don't like restricting the runtime because of decisions made in our current kernel implementations. And even if we did restrict to the current global constant, I see kernels that define their own arbitrary limits (like 5 in this op_sub implementation).

Restricting during emit/deserialize won't stop someone from manually creating a Tensor with a large number of dims, though I can't think of a way for them to inject it into execution, since the inputs already have their number of dimensions fixed (right?)

The current pattern in the kernel code is just plain unsafe. Even if we add a load-time restriction, I think that kernel code should be audited and fixed to validate assumptions about buffer lengths. Our code runs in bare-metal, embedded environments, and it needs to be paranoid and safe.