Skip to content
This repository was archived by the owner on Oct 21, 2022. It is now read-only.

Integrate some aspects of validation into deserialization #284

Closed
expenses opened this issue Oct 29, 2019 · 5 comments
Closed

Integrate some aspects of validation into deserialization #284

expenses opened this issue Oct 29, 2019 · 5 comments

Comments

@expenses
Copy link

expenses commented Oct 29, 2019

Hello! paritytech/substrate#3885 mentions that it would be nice to have the option to validate a wasm file as it's being parsed, to check for things like f32/f64s in smart contracts. There are some aspects of validation that could probably only happen once the module has been fully deserialized, but perhaps we could do something like fn deserialize_buffer(contents: &[u8], type_blacklist: &[ValueType])?

This way we could perform an early return if a type is blacklisted.

@pepyakin
Copy link
Contributor

Yeah, actually we looked into it and it feels to me that type_blacklist seems a quite a bit of overspecialization.

I think there is a chance that the mentioned issue would be better solved by a streaming parser, such as wasmparser rather than parity-wasm. But it requires a bit more research.

@expenses
Copy link
Author

Ah, ok. I had the idea of passing in something like

pub trait Validator {
	fn validate_value(&self, value: ValueType) -> Result<(), Error>;
	...
}

, perhaps that would work better?

@expenses
Copy link
Author

Then it could be used like

impl<V: Validator> Deserialize<V> for ValueType {
	type Error = Error;

	fn deserialize<R: io::Read>(reader: &mut R, validator: &V) -> Result<Self, Self::Error> {
		let val = VarInt7::deserialize(reader, &())?;

		let value_type = match val.into() {
			-0x01 => Ok(ValueType::I32),
			-0x02 => Ok(ValueType::I64),
			-0x03 => Ok(ValueType::F32),
			-0x04 => Ok(ValueType::F64),
			#[cfg(feature="simd")]
			-0x05 => Ok(ValueType::V128),
			_ => Err(Error::UnknownValueType(val.into())),
		};

		if let Ok(value_type) = value_type {
			validator.validate_value(value_type)?;
		}

		value_type
	}
}

@pepyakin
Copy link
Contributor

Yeah, callbacks are a way better way, than ad-hoc solutions like type_blacklist et al.

I am not sure though if it would benefit us though. It all depends if we could perform all required checks, analysis and transformations in one pass. If we could then a streaming parser would be a good idea. If not, or there is a chance that we might need more than one pass, then parity-wasm + callbacks might be an option.

But as I said, it would require a bit more research put into it.

@expenses
Copy link
Author

Alright, I'll hold off on making a PR or anything for now then :^)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants