Thanks John, I understand your position and rationale (Paul actually clarified this along the same lines to me earlier today). I have to admit that this would have to be quite an exotic exploit, but point taken.
sent from my phone On Nov 12, 2015 7:08 PM, "John Rose" <john.r.r...@oracle.com> wrote: > On Nov 12, 2015, at 5:48 AM, Vitaly Davidovich <vita...@gmail.com> wrote: > > > There is a very valid concern, since @Contended changes object layout and > increases object size, liberal use might tickle an overflow in HotSpot > code. Hence why it has remained internal so far. > > > > What overflow? OOM of the heap? How is that a "very valid" concern? Why > would it be used liberally? Why are you allowing users to allocate any > memory whatsoever? Why not put a cap on the size of objects non-JDK code > can allocate? :) I mean seriously, with all due respect, the occasional > "our users are dumb and misinformed" sentiment is very off-putting. > > > There's a misunderstanding here. Sadly, it relates to security policy. > > The shadowy figures with the liberal usage of sharp-edged features > are not dumb users, nor are they smart users like you whom we > unaccountably view as "dumb and misinformed", but black hat > attackers (or security researchers of any stripe), who take sharp > stuff like that and use it backwards and upside down, in ways neither > dumb nor smart users would ever dream of, to coax the JVM into > disallowed states. > > The overflow Paul refers to would not be a heap OOM but (hypothetically) > size indicators in the implementation of the JVM. Adding @C to the public > mix gives a determined attacker 3 more bits of dynamic range to maximum > instance sizes. > > I personally don't think there is any specific way to weaponize that, but > I do know, > from bitter experience, that some such expansions produce bugs. (Think > 16-bit > overflow: It has happened, it hurts when it happens.) Adding @C to the > public > mix means we have to race the black hats to find any bug tail due to the > extra > degrees of freedom in instance layout. It's not a race I want to run or > need to run, > so we are not making @C public. > > As we do value types we are having to open up object layout to many more > degrees of freedom. This will be carefully reviewed and stress-tested. > At that > point it will be very safe to add other layout hacks like @C. In fact, it > is likely > that we will be able to factor field-semantic hacks like @C (and > WeakReference > and Optional and various other interesting variable types) into value type > wrappers of the base type. > > For now, sorry. Please use the -XX and -Xbcp thingies as workarounds. > > — John >
