search

mozilla / audioipc

Cubeb Audio Remoting For Gecko
10 stars 17 forks source link

messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize` is not implemented for `[u8; 80]` #80

Closed anarchpenguin closed 4 years ago

anarchpenguin commented 4 years ago

13:48.78 error[E0277]: arrays only have std trait implementations for lengths 0..=32 13:48.78 --> media/audioipc/audioipc/src/messages.rs:214:29 13:48.78 | 13:48.78 214 | PromoteThreadToRealTime([u8; std::mem::size_of::()]), 13:48.78 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait std::array::LengthAtMost32 is not implemented for [u8; 80] 13:48.78 | 13:48.79 = note: required because of the requirements on the impl of std::fmt::Debug for [u8; 80] 13:48.79 = note: required because of the requirements on the impl of std::fmt::Debug for &[u8; 80] 13:48.79 = note: required for the cast to the object type dyn std::fmt::Debug 13:48.88 error[E0277]: the trait bound [u8; 80]: messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize is not satisfied 13:48.89 --> media/audioipc/audioipc/src/messages.rs:214:29 13:48.89 | 13:48.89 214 | PromoteThreadToRealTime([u8; std::mem::size_of::()]), 13:48.89 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize is not implemented for [u8; 80] 13:48.89 | 13:48.89 = help: the following implementations were found: 13:48.89 <[T; 0] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize> 13:48.89 <[T; 10] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize> 13:48.89 <[T; 11] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize> 13:48.89 <[T; 12] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serialize> 13:48.89 and 30 others 13:48.89 = note: required by messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Serializer::serialize_newtype_variant 13:48.93 error[E0277]: the trait bound [u8; 80]: messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Deserialize<'_> is not satisfied 13:48.93 --> media/audioipc/audioipc/src/messages.rs:214:29 13:48.93 | 13:48.93 214 | PromoteThreadToRealTime([u8; std::mem::size_of::()]), 13:48.93 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Deserialize<'_> is not implemented for [u8; 80] 13:48.93 | 13:48.93 = help: the following implementations were found: 13:48.93 <&'a [u8] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Deserialize<'de>> 13:48.93 <[T; 0] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Deserialize<'de>> 13:48.93 <[T; 10] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Deserialize<'de>> 13:48.94 <[T; 11] as messages::_IMPL_DESERIALIZE_FOR_Device::_serde::Deserialize<'de>> 13:48.94 and 30 others 13:48.94 = note: required by messages::_IMPL_DESERIALIZE_FOR_Device::_serde::de::VariantAccess::newtype_variant 13:49.44 error: aborting due to 3 previous errors 13:49.44 For more information about this error, try rustc --explain E0277. 13:49.51 error: Could not compile audioipc.

kinetiknz commented 4 years ago

Can you please share some details about your build configuration? Is this using a musl target?

anarchpenguin commented 4 years ago

Can you please share some details about your build configuration? Is this using a musl target?

Yes this is a musl target

I am using gcc-9.2.0 with current musl release 1.1.24. I have been able to build fx right up until 71.0b*

kinetiknz commented 4 years ago

We're relying on Rust's default serialization for u8 arrays <= 32 elements. Per the error, RtPriorityThreadInfo ends up being 80 elements in size with musl.

struct sched_param is 4 bytes in glibc (per bits/types/struct_sched_param.h) and 44 bytes in musl (assuming x86_64), plus padding and alignment. They both only have a single public field (sched_priority), the remaining fields are __reservedN in musl.

@padenot, I think we should adjust the serialization strategy for RtPriorityThreadInfo in https://github.com/padenot/audio_thread_priority to cover only the fields we care about. Thoughts?

Serializing reserved fields (and padding) is a potential source of info leaks, although in audioipc we're only going from a lower trust client to a higher trust server so the risk is low for our current use case.

padenot commented 4 years ago

@padenot, I think we should adjust the serialization strategy for RtPriorityThreadInfo in https://github.com/padenot/audio_thread_priority to cover only the fields we care about. Thoughts?

We get the struct and store it as is with pthread_getschedparam, and then use it to restore the previous scheduling properties with pthread_setschedparam, but not really: in practice everything has to be zero, because we're always restoring to SCHED_OTHER.

Storing is not useful, https://github.com/padenot/audio_thread_priority/pull/6 removes it.