Home All Groups Group Topic Archive Search About

IL code fails with VerificationException

Author
11 Oct 2006 12:02 PM
Paul Hatcher
Hi

We have a requirement to get the non-virtual version of GetHashCode for any
object (value or reference type). There is a call
System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode, but this fails
under some circumstances on 1.1 when passed Int32 and so we have some IL
code to achieve the same thing.

Unforturnately under medium trust, this fails with a VerificationException,
which I belive means that it can't determine whether we are type safe or
not. Can anyone help and tell me if this is type-safe and if so how to pass
the security check.

BTW The assembly is signed and has the AllowPartiallyTrustedCaller and
CLSCompliant attributes applied (I've left these out of the IL for space
purposes)

Paul

--------------
..namespace Utility
{
  .class public serializable IdentityHashCodeProvider
       implements [mscorlib]System.Collections.IHashCodeProvider
  {
    .method private hidebysig newslot final virtual
          instance int32
System.Collections.IHashCodeProvider.GetHashCode(object obj)
    {
      .override [mscorlib]System.Collections.IHashCodeProvider::GetHashCode
      ldarg.1
      call      instance int32 [mscorlib]System.Object::GetHashCode()
      ret
    }

    .method public hidebysig specialname rtspecialname instance void .ctor()
    {
      ldarg.0
      call      instance void [mscorlib]System.Object::.ctor()
      ret
    }
  }
}

Author
19 Oct 2006 9:13 PM
Ben Voigt
Show quote Hide quote
"Paul Hatcher" <pa***@grassoc.co.uk> wrote in message
news:O7h5l0S7GHA.1492@TK2MSFTNGP02.phx.gbl...
> Hi
>
> We have a requirement to get the non-virtual version of GetHashCode for
> any object (value or reference type). There is a call
> System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode, but this fails
> under some circumstances on 1.1 when passed Int32 and so we have some IL
> code to achieve the same thing.
>
> Unforturnately under medium trust, this fails with a
> VerificationException, which I belive means that it can't determine
> whether we are type safe or not. Can anyone help and tell me if this is
> type-safe and if so how to pass the security check.

What is the output of PEVerify?

Show quoteHide quote
>
> BTW The assembly is signed and has the AllowPartiallyTrustedCaller and
> CLSCompliant attributes applied (I've left these out of the IL for space
> purposes)
>
> Paul
>
> --------------
> .namespace Utility
> {
>  .class public serializable IdentityHashCodeProvider
>       implements [mscorlib]System.Collections.IHashCodeProvider
>  {
>    .method private hidebysig newslot final virtual
>          instance int32
> System.Collections.IHashCodeProvider.GetHashCode(object obj)
>    {
>      .override [mscorlib]System.Collections.IHashCodeProvider::GetHashCode
>      ldarg.1
>      call      instance int32 [mscorlib]System.Object::GetHashCode()
>      ret
>    }
>
>    .method public hidebysig specialname rtspecialname instance void
> .ctor()
>    {
>      ldarg.0
>      call      instance void [mscorlib]System.Object::.ctor()
>      ret
>    }
>  }
> }
>
Author
26 Oct 2006 10:15 PM
Brian Stern
Paul,

This behavior is actually expected.  It is considered a potential security
risk to be able to bypass a derived virtual method.  This is a safe and
legal operation within your own class heirarchy (ie base.VirtualMethod())
but not in a different class.

What problem are you trying to solve by bypassing the derived GetHashCode?

Brian Stern [MSFT]



Show quoteHide quote
"Paul Hatcher" <pa***@grassoc.co.uk> wrote in
news:O7h5l0S7GHA.1492@TK2MSFTNGP02.phx.gbl:

> Hi
>
> We have a requirement to get the non-virtual version of GetHashCode
> for any object (value or reference type). There is a call
> System.Runtime.CompilerServices.RuntimeHelpers.GetHashCode, but this
> fails under some circumstances on 1.1 when passed Int32 and so we have
> some IL code to achieve the same thing.
>
> Unforturnately under medium trust, this fails with a
> VerificationException, which I belive means that it can't determine
> whether we are type safe or not. Can anyone help and tell me if this
> is type-safe and if so how to pass the security check.
>
> BTW The assembly is signed and has the AllowPartiallyTrustedCaller and
> CLSCompliant attributes applied (I've left these out of the IL for
> space purposes)
>
> ...