At 11:38 PM -0700 7/18/99, Joshua Bloch wrote:
> In a recent phone conversation with Dan Scales, I presented an argument
>for "initialization safety" which Dan encouraged me to share with the list.
>
> Simply put, the argument is that the lack of initialization safety may
>be exploited by an attacker to compromise the security of a library that
>takes immutable objects on input.
OK. I'm going to put on my weak memory model hat for this message.
Say that an attacker invokes a method in class Foo and passes it an
object of class Bar. Foo expects that Bar doesn't change in unexpected ways,
and the attacker will exploit this to do something bad.
What must be true here? In order for Foo to reasonably trust that an object
of type Bar won't change unexpectedly, both of the following must be true:
* Foo must trust Bar
* Either instances of Bar must be immutable, or all of the ways of
accessing a Bar must be properly synchronized.
If all of the ways of accessing Bar are properly synchronized, we
won't have any problem.
Note that simply knowing that all of the fields in Bar are final
isn't sufficient. If Foo doesn't trust Bar, then Foo should worry
that Bar could start initialization of a Bar, pass the partially
initialized object to Foo, and then finish initializing the Bar.
So we have:
* Foo must trust Bar
* instances of Bar must have immutable semantics
Now, if Bar has immutable semantics, and Foo trusts Bar, Foo can
require/expect that Bar is written in a way to guarantee
immutability, even in face of a weak memory model. We've been talking
about the treatment of final and volatile in the memory model. If we
define something so that some combination of those attributes
guarantees that the field is never stale, then that provides an idiom
that allows Bar to provide absolute immutability.
If, as I suggested before, we define a semantics for "final volatile"
that guarantees the value is never stale but doesn't incur the usual
cost of volatile variables, then on machines with memory models at
least as strong as RMO, there would be no additional costs for
marking fields as final volatile.
I'm not sure what objects would really need this treatment. Obviously
String, probably Class and CodeSource. Probably requires some thought
and a code review of all of java.security.
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:17 EDT