harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [classlib][archive]Security policy leads to vm crashes in loading class of JarFile
Date Thu, 19 Oct 2006 05:20:47 GMT
2006/10/19, Leo Li <liyilei1979@gmail.com>:
> But there really contains code about launcher in Harmony/luni, and this
> part is maintained by Harmony classlib but not VM. :)
Um, I thought all Harmony code is maintained by us community ;)
As discussed in an older thread, launcher will be moved to "tools" some day.

>
> On 10/19/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> >
> > 2006/10/19, Leo Li <liyilei1979@gmail.com>:
> > >  It is quite a dilemma: VM is free to choose the strategy of loading
> > library
> > > while the sequence is related to classlib.
> > >  In my opinion, it is classlib that has enough information and the
> > > responsibility to decide the library loading sequence.
> > >  Since the launcher is in the control of classlib, is it possible that
> > after
> > > getting the JavaVM, manually load the required library then run the main
> > > method?
> >
> > Nope, the launcher is not a part of classlib and will not present in
> > all configurations (e.g. browser plugin or direct use of Invocation
> > API).
> > IMHO #3 is too crooked therefore inacceptable, and indeed we have to
> > state a VMI contract for loading natives needed by classlib: #1, #4 or
> > some other. I may suggest:
> > 5. Reuse "bootclasspath.properties" solution. That is, there is always
> > mandatory hyluni lib, which can set up some property value indicating
> > a list of required libraries - as it is done now for bootclasspath
> > jars. After loading hyluni and calling its JNI_OnLoad, VM can read
> > this list and load other libs.
> >
> > NB. Currently DRLVM follows #1, that's why it works.
> >
> > >
> > >
> > > On 10/18/06, Paulex Yang <paulex.yang@gmail.com> wrote:
> > > >
> > > > Alexey Varlamov wrote:
> > > > > Can't we use lazy initialization here? I had similar experience with
> > > > > this class in the past, and think it should not be so fragile to
> > > > > initialization sequence. And definitely it should not affect whole
> > VM
> > > > > run.
> > > > Hmm...lazily loading for Msg class is good, but I'm afraid it's not
> > the
> > > > "sweet point" of this problem, because in this case, the exception is
> > > > *really* thrown by j.n.URL, so that you cannot avoid loading resource
> > > > bundle(btw, I just found that the full stacktrace hasn't been pasted
> > > > yet[1]).  lI suspect the issue is that the hyarchive.dll/so has not
> > been
> > > > loaded yet when this exception happens, so I added this line to the
> > > > static initialization part of ZipFile
> > > >
> > > >    static {
> > > > +        System.loadLibrary("hyarchive"); //$NON-NLS-1$
> > > >        ntvinit();
> > > >    }
> > > >
> > > > The test codes pass happily. I want to commit this as work around if
> > no
> > > > one objects, but I still think a general solution for this kind of
> > issue
> > > > is necessary. There are several classes in archive module need native
> > > > library, Adler32, CRC32, Deflater, Inflater and ZipFile, only
> > explicitly
> > > > load hyarchive here cannot guarantee bug free, and some other modules
> > > > (nio, text etc) have same risk. I have some proposals:
> > > >
> > > > 1. Load classlib native libraries as early as possible in VM, as what
> > we
> > > > do for hyluni, this is safe but the concern is all the Harmony
> > > > compatible VM needs to do this, unacceptable.
> > > > 2. Load them early enough, like what we do now in IBM VME, the
> > hyarchive
> > > > is loaded during j.l.System static init, it was considered early
> > enough,
> > > > but sadly this case shows that we cannot image all cases, even for a
> > > > relative general case
> > > > 3. Create an init class like below, and all classes needs native
> > library
> > > > must load this init class at first, this works but works in ugly
> > way...
> > > >       public class Init{
> > > >          static{
> > > >             System.loadLibrary("blabla");
> > > >          }
> > > >       }
> > > >       public class SomeClassNeedsNative{
> > > >          static{
> > > >             Class.forName("Init"); // the class loading should only
> > > > happen once so that the native library is loaded only once.
> > > >          }
> > > >       }
> > > > 4. Produce some contract like Jar_OnLoad() which is described in
> > > > MANIFEST.MF, so that any class loader loading the jar at first time
> > will
> > > > execute that method, like JNI_OnLoad or so. This solution seems
> > general
> > > > and elegant, but needs yet another agreement between Harmony VM and
> > > > classlib, further it may make the jar not compatible with other VM.
> > > >
> > > > Comments? More ideas?
> > > >
> > > > [1] java.lang.UnsatisfiedLinkError: java/util/zip/ZipFile.ntvinit()V
> > > >    at java.util.zip.ZipFile.<clinit>(ZipFile.java:50)
> > > >    at java.lang.J9VMInternals.initializeImpl(Native Method)
> > > >    at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
> > > >    at java.lang.J9VMInternals.initialize(J9VMInternals.java:144)
> > > >    at
> > > > com.ibm.oti.vm.AbstractClassLoader.fillCache(AbstractClassLoader.java
> > :95)
> > > >    at
> > > > com.ibm.oti.vm.AbstractClassLoader.getResourceAsStream(
> > > > AbstractClassLoader.java:134)
> > > >    at java.util.ResourceBundle$1.run(ResourceBundle.java:282)
> > > >    at java.util.ResourceBundle$1.run(ResourceBundle.java:1)
> > > >    at
> > > > java.security.AccessController.doPrivileged(AccessController.java:179)
> > > >    at java.util.ResourceBundle.handleGetBundle(ResourceBundle.java
> > :277)
> > > >    at java.util.ResourceBundle.getBundle(ResourceBundle.java:134)
> > > >    at org.apache.harmony.luni.util.MsgHelp$1.run(MsgHelp.java:114)
> > > >    at
> > > > java.security.AccessController.doPrivileged(AccessController.java:179)
> > > >    at org.apache.harmony.luni.util.MsgHelp.setLocale(MsgHelp.java:112)
> > > >    at org.apache.harmony.luni.util.Msg.<clinit>(Msg.java:49)
> > > >    at java.lang.J9VMInternals.initializeImpl(Native Method)
> > > >    at java.lang.J9VMInternals.initialize(J9VMInternals.java:177)
> > > >    at java.net.URL.<init>(URL.java:296)
> > > >    at java.net.URL.<init>(URL.java:156)
> > > >    at
> > > > org.apache.harmony.security.fortress.PolicyUtils.getPolicyURLs(
> > > > PolicyUtils.java:445)
> > > >    at
> > > > org.apache.harmony.security.fortress.DefaultPolicy.refresh(
> > > > DefaultPolicy.java:278)
> > > >    at
> > > > org.apache.harmony.security.fortress.DefaultPolicy.<init>(
> > > > DefaultPolicy.java:184)
> > > >    at
> > > > org.apache.harmony.security.fortress.DefaultPolicy.<init>(
> > > > DefaultPolicy.java:173)
> > > >    at java.lang.Class.newInstanceImpl(Native Method)
> > > >    at java.lang.Class.newInstance(Class.java:1250)
> > > >    at java.security.Policy$1.run(Policy.java:156)
> > > >    at
> > > > java.security.AccessController.doPrivileged(AccessController.java:179)
> > > >    at java.security.Policy.getDefaultProvider(Policy.java:151)
> > > >    at java.security.Policy.getAccessiblePolicy(Policy.java:191)
> > > >    at java.security.Policy.getPolicy(Policy.java:132)
> > > >    at org.apache.harmony.luni.util.PriviAction.run(PriviAction.java
> > :133)
> > > >    at
> > > > java.security.AccessController.doPrivileged(AccessController.java:179)
> > > >    at java.lang.System.setSecurityManager(System.java:825)
> > > >    at java.lang.System.installSecurityManager(System.java:155)
> > > >    at java.lang.System.completeInitialization(System.java:117)
> > > >    at java.lang.Thread.<init>(Thread.java:129)
> > > > >
> > > > > 2006/10/18, Paulex Yang <paulex.yang@gmail.com>:
> > > > >> A little further hack shows that, the cause is o.a.h.luni.util.Msg
> > > > >> cannot be initialized so early, which is the exception message
i18n
> > > > >> helper class. Its static init codes try to load ResourceBundle
but
> > > > >> failed. The new i18n helper o.a.h.l.internal.nls.Messages has
same
> > > > >> issue. I modified the java.net.URL ln.296 as below, and the test
> > > > passed.
> > > > >> -                throw new MalformedURLException(
> > > > >> -                        org.apache.harmony.luni.util.Msg.getString
> > (
> > > > >> -                        "K00d8", spec)); //$NON-NLS-1$
> > > > >> +               throw new MalformedURLException("exception message
> > > > >> here");
> > > > >>
> > > > >> Leo Li wrote:
> > > > >> > Hi, all:
> > > > >> >     During the self-hosting of Derby, I found a security
> > policy  if
> > > > is
> > > > >> > applied will lead to errors in loading the class of JarFile.
IBM
> > vm
> > > > >> > will throw java/lang/UnsatisfiedLinkError:
> > java/util/zip/ZipFile.ntvi
> > > > >> > while
> > > > >> > drlvm will crash with "SEH handler: shutdown errorSEH handler:
> > too
> > > > >> many
> > > > >> > shutdown errors..."
> > > > >> >
> > > > >> >     Here is the testcase:
> > > > >> >
> > > > >> >
> > > > >> > import java.util.jar.*;
> > > > >> > public class TestJarFile {
> > > > >> >
> > > > >> > public static void main(String[] args) throws Exception{
> > > > >> >  System.out.println(JarFile.CENATT);
> > > > >> >   }
> > > > >> >
> > > > >> > }
> > > > >> >
> > > > >> > And the attachment is the derby_tests.policy.
> > > > >> >
> > > > >> > Then run:
> > > > >> >
> > > > >> > java -Djava.security.manager
> > > > >> > -Djava.security.policy=derby_tests.policyTestJarFile
> > > > >> >
> > > > >> > Run passes,
> > > > >> >
> > > > >> > Harmony on IBM VM fails with java/lang/UnsatisfiedLinkError:
> > > > >> > java/util/zip/ZipFile.ntvi
> > > > >> >
> > > > >> > Harmony on Drlvm fails with SEH handler: shutdown errorSEH
> > handler:
> > > > >> > too many
> > > > >> > shutdown errors
> > > > >> >
> > > > >> > If the security manager is not specified, Harmony passes.
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Paulex Yang
> > > > >> China Software Development Lab
> > > > >> IBM
> > > > >>
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > >> To unsubscribe, e-mail:
> > harmony-dev-unsubscribe@incubator.apache.org
> > > > >> For additional commands, e-mail:
> > harmony-dev-help@incubator.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail:
> > harmony-dev-help@incubator.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Paulex Yang
> > > > China Software Development Lab
> > > > IBM
> > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Leo Li
> > > China Software Development Lab, IBM
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message