Java中的泛型 – 与遗留代码互操作

JVM的基本安全模型依赖于对象是运行时认为它的类型.

我读了一篇引人入胜的论文,详细介绍了对运行Java的机器的攻击,该机器涉及使用加热灯来大幅增加内存错误.然后,他们使用了一个程序,数十亿个对象在内存中策略性地对齐,并等待一个有零星的位翻转.这样做会欺骗JVM认为它正在处理不同类型的对象,并最终允许JVM运行任意代码(对于完整的读取,请参阅Using Memory Errors to Attack a Virtual Machine).

他们使用位翻转的事实与泛型无关.但是,该文章详细介绍了欺骗运行时思考对象的不同类型的能力.总而言之,想象一下你有A和B类：

class A {
    public long data = 0;
}

class B {
}

如果你能以某种方式欺骗JVM允许这样做：

A aButActuallyB = someMagicAssignment(new B());

someMagicAssignment是一个可以引用B的方法,并以某种方式将引用对象作为A返回.然后考虑当你执行时实际会发生什么：

aButActuallyB.data = 0x05124202;

您可能正在写入JVM原始内存中的任意数据！例如,该数据可以是方法的位置.将其更改为指向某个字节数组的内容可以让您随后运行任意代码.

所以当Oracle说

the type safety and integrity of the Java virtual machine are never at risk,even in the presence of unchecked warnings.

它的含义是即使你能做到这一点：

public static <T> T someMagicAssignment(B b){ 
   return (T) b; //unchecked cast warning
}

然后调用它：

A a = MyClass.<A>someMagicAssignment(new B());

这仍然会在分配到a时进行运行时检查.

因此,编写该方法someMagicAssignment并不比以前容易.泛型不会以任何方式增加此攻击向量的表面区域,因为JVM在其内部类型系统中忽略了泛型.从来没有JVM允许您为List< String>提供方法,然后让该方法对该列表的元素执行String操作,而不在运行时检查元素实际上是字符串.绝不允许你在没有人工检查的情况下将B视为A.