Repository navigation
SerializationGuard bloats the binary size on NAOT #87470
Description
Currently when calling Process.Start it brings the whole reflection stack with it even when the Switch.System.Runtime.Serialization.SerializationGuard.AllowProcessCreation is specified. This adds about 1MB to the final binary size.
The SerializationGuard seems to use reflection internally to retrieve the switch here which ends up rooting the reflection stack. It would be nice if the whole reflection guard concept would be possible to trim away on NAOT.
Activity
aromaa commentedon Jun 13, 2023
Related #44369. Noticed it after I changed the title to be more general last minute. I'm more concerned about the
Process.Startmyself so this might be more actionable as a subset?danmoseley commentedon Jun 13, 2023
Cc @GrabYourPitchforks
jkotas commentedon Jun 13, 2023
Can we at least introduce a feature switch to allow people who do not want to pay for the serialization guard overheads to opt-out of it?
stephentoub commentedon Jun 13, 2023
I'd be in favor of deleting it entirely, especially with BinaryFormatter disabled by default in most workloads and scheduled for extinction. Short of that, a feature switch in the meantime makes sense. Could we not just use the existing one for BinaryFormatter to also guard the guard?
MichalStrehovsky commentedon Jun 13, 2023
Per #44369 (comment) this is also used in deserialization of DataTable so it's not BinaryFormatter only.
Looks like users can configure DataSet/DataTable deserialization to be a binaryformatter-like security nightmare. I wonder whether that mode should also be obsoleted together with BinaryFormatter.
Debloat serialization guard
Debloat serialization guard (#89706)