[Memory64] Wasm table import가 address type 일치 여부를 확인하지 않는 문제

Wasm table linking checked type, size, and max — everything but the address width.

Component: JSC WebAssembly | 862994e

WebAssembly의 Memory64 proposal은 table(그리고 memory)을 i32 또는 i64 address로 인덱싱할 수 있게 합니다. Address width가 offset 연산과 bounds check에 영향을 주기 때문에, JIT와 interpreter는 table이 어떤 address type을 선언했는지에 따라 call_indirect, table.get/table.set 등에 대해 서로 다른 indexing code를 생성합니다. Import validation은 원래 module이 정적으로 선언한 assumption과 일치하는 table에 대해서만 동작하도록 보장하는 경계 역할을 해야 합니다.

Source/JavaScriptCore/wasm/js/WebAssemblyModuleRecord.cpp

 if (!Wasm::isSubtype(actualType, expectedType) || !Wasm::isSubtype(expectedType, actualType))
     return exception(createJSWebAssemblyLinkError(globalObject, vm, importFailMessage(import, "Table import"_s, "provided a 'type' that is wrong"_s)));
 
+ if (table->table()->addressType() != moduleInformation.tables[import.kindIndex].addressType())
+     return exception(createJSWebAssemblyLinkError(globalObject, vm, importFailMessage(import, "Table import"_s, "provided an 'address' that is different from the module's declared 'address' import table attribute"_s)));
+
 // ii. Append v to tables.
 // iii. Append v.[[Table]] to imports.
 m_instance->setTable(vm, import.kindIndex, table);

기존 table import linking은 element type, initial size, maximum size는 검증했지만, 제공된 table의 addressType()을 module이 선언한 import addressType()과 비교하는 절차는 없었습니다. 패치는 이 cross-check를 추가해 mismatch 시 LinkError를 던지도록 했습니다. 이제 i32 table은 table64 import를 충족시킬 수 없으며, 반대의 경우도 마찬가지입니다.

Significance

이 check가 없으면, 64-bit table index를 전제로 컴파일된 module이 32-bit indexing 내부 구조를 가진 table object와 link될 수 있었습니다. 한쪽 address width를 전제로 생성된 index/bounds-check code가 실제로는 다른 address width로 구성된 table을 대상으로 실행되는 상황이 가능해집니다. Wasm linking 경계에서 발생하는 address-width confusion으로, table addressing에 적용된 type-confusion 유형에 해당합니다.

Audit directions

Memory64 import 경계에서의 address-type parity 검증 누락. 이번 건은 정적으로 가정한 addressing이 linked object와 실제로 일치하는지를 보장해야 할 바로 그 지점에서 발생한 validation gap입니다. 좁혀서 볼 지점은, memory import도 table과 동일하게 Memory64 address-type 구분을 가지므로 i32 대 i64 address-type parity가 동일하게 강제되는지 확인하는 것입니다. WebAssemblyModuleRecord의 table path와 함께 memory-import path도 점검할 필요가 있습니다. Review 시에는, element type / limits는 검증하면서 addressType()은 검증하지 않는 Memory64 import-linking 지점을 식별 패턴으로 삼아야 합니다.
실제 linked object가 아니라 static module info에서 bounds-check width를 가져오는 경로. 이번 link-time fix가 적용되더라도, JIT나 interpreter의 fast path가 module이 선언한 table attribute에서 bounds-check나 offset width를 읽어오고, 실제로 linked된 table의 addressType()을 런타임에 재검증하지 않는다면 여전히 노출된 상태로 남습니다. call_indirect / table.get / table.set codegen을 따라가면서 addressing width가 어디서 결정되는지 추적할 필요가 있습니다. 가장 넓게 볼 지점은, 서로 다른 module에서 import되어 address type이 다른 table 사이의 table.copy / table.init 같은 cross-table 연산입니다. 이런 경로들이 address-type 호환성을 가정하지 않고 실제로 검증하는지 확인해야 합니다.