| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and privileged access)
This review focuses on how we perform permission checks,
or better - do we circumvent some assuming full privileges ?
Some native methods do need extra permission validation, i.e. loading native libraries.
Further more AccessController.doPrivileged(..) shall not cover generic code
exposing a critical feature to the user.
Further more .. we should rely on the SecuritManager, i.e. AccessControlContext's
'checkPermission(Permission)' code to comply w/ fine grained permission access.
It is also possible to have full permission w/o having any certificates (-> policy file).
+++
We remove implicit AccessController.doPrivileged(..) from within our trusted code
for generic methods, like Property access, temp. files.
+++
SecurityUtil:
- Remove 'getCommonAccessControlContext(Class<?> clz)',
which returned a local AccessControlContext for later restriction
if the passed class contains all certificates as the 'trusted' GlueGen class has.
- Simply expose convenient permission check methods relying on
SecurityManager / AccessControlContext.
PropertyAccess:
- 'protected static void addTrustedPrefix(..)' requires AllPermissions if SecurityManager is installed.
- Remove implicit doPrivileged(..) triggered by passed AccessControlContext instance,
only leave it for trusted prefixes.
IOUtil:
- Remove all doPrivileged(..) - Elevation shall be performed by caller.
DynamicLinker:
- 'public long openLibraryLocal(..)' and 'public long openLibraryGlobal(..)'
may throw SecurityException, if a SecurityManager is installed and the dyn. link permission
is not granted in the calling code.
Implemented in their respective Unix, OSX and Windows manifestation.
Caller has to elevate privileges via 'doPrivileged(..) {}' !
+++
Tests:
- Property access
- File access
- Native library loading
Manual Applet test (unsigned, but w/ SecurityManager and policy file):
> gluegen/test/applet
Applet has been tested w/ signed JAR w/ Firefox and Java7 on GNU/Linux as well.
Manual Application test (unsigned, but w/ SecurityManager and policy file):
com.jogamp.junit.sec.TestSecIOUtil01
- Run w/ SecurityManager and policy file:
- gluegen/scripts/runtest-secmgr.sh
- Run w/o SecurityManager:
- gluegen/scripts/runtest.sh
|
|
|
|
| |
whitespace tokenizer); String match: Store end-of-match and flag defined components.
|
| |
|
|
|
|
| |
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
|
|
| |
Assume Lock
If timeout has been reached but the lock has been released, the lock has to be assumed.
|
|
|
|
| |
Exclude java.part.awt in android gluegen-rt.
|
|
|
|
|
|
|
|
| |
/proc/self/exe (Linux) or a found java/jvm native lib.
- PlatformPropsImpl.queryABITypeImpl: Check Elf Header for ARM + !ANDROID (i.e. add other OS than Linux, use native java/jmv lib)
- NativeLibrary.enumerateLibraryPaths: Add 'sun.boot.library.path' to enumeration!
- TestElfReader01: Add test for finding java/jvm native lib and parse it
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to distinguish ARM soft-float/hard-float (part-2)
+ /**
+ * Returns the {@link ABIType} of the current platform using given {@link CPUType cpuType}
+ * and {@link OSType osType} as a hint.
+ * <p>
+ * Note the following queries are performed:
+ * <ul>
+ * <li> not {@link CPUFamily#ARM} -> {@link ABIType#GENERIC_ABI} </li>
+ * <li> else
+ * <ul>
+ * <li> not {@link OSType#LINUX} -> {@link ABIType#EABI_GNU_ARMEL} </li>
+ * <li> else
+ * <ul>
+ * <li> Elf ARM Tags -> {@link ABIType#EABI_GNU_ARMEL}, {@link ABIType#EABI_GNU_ARMHF} </li>
+ * </ul></li>
+ * </ul></li>
+ * </ul>
+ * </p>
+ * <p>
+ * Elf ARM Tags are read using {@link ElfHeader}, .. and {@link SectionArmAttributes#abiVFPArgsAcceptsVFPVariant(byte)}.
+ * </p>
+ *
+ * @param cpuType
+ * @param osType
+ * @return
+ */
+ private static final ABIType queryABITypeImpl(CPUType cpuType, OSType osType) {
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
distinguish ARM soft-float/hard-float (part-1)
https://jogamp.org/bugzilla/show_bug.cgi?id=681
+ * References:
+ * <ul>
+ * <li>http://linux.die.net/man/5/elf</li>
+ * <li>http://www.sco.com/developers/gabi/latest/contents.html</li>
+ * <li>http://infocenter.arm.com/
+ * <ul>
+ * <li>ARM IHI 0044E, current through ABI release 2.09</li>
+ * <li>ARM IHI 0045D, current through ABI release 2.09</li>
+ * </ul></li>
Added self contained jogamp.common.os.elf package w/ entry point class ElfHeader
to read a RandomAccessFile and parse it as an ELF file.
ELF Parsing completness:
- Header: OK
- SectionHeader: OK
- Section Type SHT_ARM_ATTRIBUTES: OK
- Will be read into SectionArmAttributes
- Used to distinguisgh soft/hard VFP float
Tested manually on:
- Linux intel 32bit / 64bit, arm soft-float and hard-float
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClassLoader for SYS-Packages w/ native libs, and non cached child ClassLoader for USR-Packages
Android's Dalvik VM, like a JVM, cannot load a native library from one location by multiple ClassLoader.
Since we don't like to hardcode the system-packages, as it was before, i.e. "com.jogamp.common", "javax.media.opengl",
we need to either copy the libs or use parenting of cached ClassLoader.
The latter is chosen, since it's faster and uses less resources.
- System-packages are passed through from the user 'List<String> LauncherUtil.BaseActivityLauncher::getSysPackages()'
to the ActivityLauncher, which instantiates the ClassLoader.
- No more hard-reference the system-packages in ClassLoaderUtil ("com.jogamp.common", "javax.media.opengl"),
just use the new user provided system-packages.
- The system-packages denominate a hash-key for caching, a new ClassLoader is created and mapped
if it does not yet exist.
- A non-chached user-packages ClassLoader is created using the cached system-packages ClassLoader as it's parent.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- ActivityLauncher
- no finish() from onDestroy()
- MainLauncher
- finish activity after returning 'main()' returns
- no finish() from onDestroy()
- adb-launch-main:
- Clear logcat
- Wait until activity is stopped
- Dump logcat to local logfile
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
May break GCJ/ECJ .. needs to be revised.
- Adding JAVA_6 in PlatformPropsImpl
- Buffers.isDirect() chooses fast-path iff JAVA_6, otherwise using reflection (GCJ/ECJ)
- Adding JAVA_6 info in VersionUtil
- API doc: Refine JAVA_SE and JAVA_6 spec.
TODO: In case GCJ etc is unable to compile the JAVA_6 code
even though it uses a static condition (probably not),
We have to wrap isStatic in an own class, one for JAVA_6 and one for <= 1.5.
This will be a good exercise for further issues we may have w/ Java <= 1.5.
|
|\ |
|
| |
| |
| |
| | |
Signed-off-by: Xerxes Rånby <[email protected]>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActivityLauncher order of delegation/super activity callbacks.
- StaticContext:
- Add ViewGroup for standalone tests w/ UI
- MainLauncher/LauncherUtil:
- Complete launching a main() class from our activity launcher
- adding main-cmdline-args
- ActivityLauncher
- Fix order of delegation/super activity callbacks.
|
|
|
|
|
|
|
| |
execute the runnable.
For some 'rare' AWT/GL lifecycle actions, it is required to only run the command on the AWT-EDT,
hence adding an argument determining the restriction.
|
|
|
|
|
|
|
|
|
|
|
|
| |
ApplicationInfo's nativeLibraryDir (API level 9).
On Android > 4.0.3 (maybe even earlier), w/ a split filesystem (internal and SDCARD)
the JNI libs maybe stored at a different location than it's data path.
ApplicationInfo's nativeLibraryDir properly determines the JNI storage location, hence use it.
Prev. code also derived JNI lib path by the launcher's ApplicationInfo's nativeLibraryDir,
which might be different than the user package's nativeLibraryDir.
This is especially true, since the launcher may not hold any native libraries.
|
|
|
|
|
|
|
|
|
|
|
|
| |
SingletonInstanceFileLock error message
The getName() call here is currently calling Thread.getName() inherited by the
anonymous inner class. This is ambiguous, and likely meant to call the getName()
method of SingletonInstanceFileLock, which would output the lockfile name.
In any event, infoPrefix() is already adding the Thread name for us.
Signed-off-by: Harvey Harrison <[email protected]>
|
|
|
|
| |
same port w/ subsequent instance, i.e. overcome TO state when JVM crashed
|
|
|
|
| |
start, otherwise we may collide w/ a failed start. Misc: Cleanup / reuse strings.
|
|
|
|
| |
unlock fails ; Added unit tests.
|
|
|
|
| |
Runnable r)" to be used directly
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARMv7hf -> ARMv6hf, ARMv7-soft -> ARMv5te/ARMV6 (soft)
platform build config files:
lib/gluegen-cpptasks-linux-armv7.xml -> lib/gluegen-cpptasks-linux-armv6.xml
lib/gluegen-cpptasks-linux-armv7hf.xml -> lib/gluegen-cpptasks-linux-armv6hf.xml
properties:
isLinuxARMv7 -> isLinuxARMv6
isLinuxARMv7Armel -> isLinuxARMv6Armel
isLinuxARMv7Armhf -> isLinuxARMv6Armhf
isAndroidARMv7 -> isAndroidARMv6
isAndroidARMv7Armel -> isAndroidARMv6Armel
isAndroidARMv7Armhf -> isAndroidARMv6Armhf
targets:
compiler.cfg.linux.armv7 -> compiler.cfg.linux.armv6
linker.cfg.linux.armv7 -> linker.cfg.linux.armv6
compiler.cfg.linux.armv6:
<compilerarg value="-fpic" />
<compilerarg value="-march=armv5te" />
<compilerarg value="-marm" />
<compilerarg value="-mfloat-abi=softfp" />
<linkerarg value="-fpic" />
<linkerarg value="-march=armv5te" />
<linkerarg value="-marm" />
<linkerarg value="-mfloat-abi=softfp" />
<linkerarg value="-nostdlib" />
<linkerarg value="-Bdynamic" />
compiler.cfg.linux.armv6hf:
<compilerarg value="-fpic" />
<compilerarg value="-march=armv6" />
<compilerarg value="-marm" />
<compilerarg value="-mfloat-abi=hard" />
<linkerarg value="-fpic" />
<linkerarg value="-march=armv6" />
<linkerarg value="-marm" />
<linkerarg value="-mfloat-abi=hard" />
<linkerarg value="-nostdlib" />
<linkerarg value="-Bdynamic" />
gluegen-cpptasks-android-armv6.xml:
<compilerarg value="-fpic" />
<compilerarg value="-march=armv6" />
<compilerarg value="-mfloat-abi=softfp" />
<compilerarg value="-marm" />
<linkerarg value="-march=armv6" />
<linkerarg value="-mfloat-abi=softfp" />
<linkerarg value="-marm" />
<linkerarg value="-nostdlib" />
<linkerarg value="-Bdynamic" />
|
|
|
|
|
|
|
|
| |
- LockExt -> ThreadLock - clarifying semantics (API Change)
- ThreadLock: Remove isOwner(), use isOwner(Thread.currentThread)
- adding @Override
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1468286bf569a493e4fdb887d5f3732f88c8cec3) 'update' scenario in same JVM instance.
TempFileCache/LauncherTempFileCache were using the system property
'jnlp.jogamp.tmp.cache.root', if set.
However, in case one JVM launched an old GlueGen (Applet)
and then launching a new GlueGen (Applet) w/ a new tmpDir location,
the property is still set but the tmpRootDir location does not exist.
This patch tolerates this situation and cont. setting a new tmpRootDir.
Example:
JVM1.GlueGen1 tmpDir: /tmp/, tmpRootDir: /tmp/jogamp.tmp.cache_000000/
JVM1.GlueGen2 tmpDir: /tmp/jogamp_0000/, tmpRootDir: /tmp/jogamp_0000/file_cache/
Misc:
- IOUtil: Always use 'jogamp_xxxx' as the sys-temp subfolder for tmpDir
- JNILibLoaderBase: Remove unised import
- TempJarCache.validateCertificates(): Add OK DEBUG output.
|
|
|
|
|
|
|
|
|
|
|
|
| |
library loading
Some Platform field declarations and it's static initialization has been delegated
to it's new abstract super class PlatformPropsImpl to solve
static initialization interdependencies w/ the GlueGen native library loading
and it's derived information {@link #getMachineDescription()}, {@link #is32Bit()}, ..<br>
This mechanism is preferred in this case to avoid synchronization and locking
and allow better performance accessing the mentioned fields/methods.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is mounted w/ noexec ; IOUtil API change!
Test whether executable files can be launched in temporary folder
by trying to run an empty executable file - if !( WINDOWS | OPENKODE )
TempDir:
1) ${java.io.tmpdir}/jogamp
2) $XDG_CACHE_HOME/jogamp - if !( ANDROID | MACOS | WINDOWS | OPENKODE )
3) $HOME/.jogamp
$XDG_CACHE_HOME defaults to $HOME/.cache
- TempFileCache: ${TempDir}/file_cache -> ${java.io.tmpdir}/jogamp/file_cache
- LauncherTempFileCache: ${TempDir}/file_cache -> ${java.io.tmpdir}/jogamp/file_cache
+++
AndroidUtils*.getTempRoot(): Remove unused AccessControlContext param
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specific classes for non Android platforms.
Android specifics are delegated via class AndroidUtils,
which uses reflection to call AndroidUtilsImpl if platform is Android.
Android code is confined to the packages:
jogamp.common.os.android.*
jogamp.android.launcher.*
and only included when compiled for the Android platform.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
APKs to add to classpath
MainLauncher is capable of launching a traditional static main method from a activity.
TODO:
- parametrize the APK list (junit, ..)
- pass-through the activity instance to be used w/ NEWT AndroidWindow
|
| |
|
| |
|
|
|
|
| |
/ API doc cleanup; DynamicLibraryBundle: Add getDefaultRunnableExecutor()
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android ClassLoaderUtil cleanup;
- Add 'asset' URLConnection
- Please read API doc 'PiggybackURLConnection' and 'AssetURLConnection'
- Solves generic resource handling where platform locations may differ,
ie ClassLoader lookup on Android in the 'assets/' subfolder.
- New Android 'AssetDexClassLoader' uses 'assets/' folder for findResource(..)
- aapt.signed (our APK ant task)
- uses 'assets/' folder
- adds the 'assetsdir' attribute allowing to copy other assets into the APK
- IOUtil uses URLConnection / incr. effeciency
- using URLConnection on all getResource(..) since URL
is connected anyways for validation and URLConnection can be used by caller right away
- String getRelativeOf(URL, String) -> URL getRelativeOf(URL, String)
- preserves scheme, authority, etc
- simple parentOf handling, more efficient
- reusing new 'asset' protocol impl.
- Android ClassLoaderUtil cleanup;
- Use createClassLoader(..) impl for build-in static jogamp and user APKs,
which removes code redundancy
Tests: New code path, especially 'assets' are covered by new unit tests, no regressions on Linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActivityLauncher provides delegating Activities, allowing the user to:
- daisy chain custom APK classes and native libraries to the classpath
- name one custom activity which gets delegated to, the downstream activity
Overview:
[User:a1] -- (usr-data) --> [Launcher] -> [User:a2] + using [other packages..]
[User APK] - The user provided APK
[JogAmp APK] - JogAmp APKs
[User:a1] - The initial user activity, which starts the [Launcher].
Providing data to [Launcher]: [User:a2], [User APK]
Resides in [User APK]
[User:a2] - The actual downstream 'real' activity, spoiled w/ full fledged ClassLoader
having access to all packages as requested, ie. [User APK], ..
Resides in [User APK]
[Launcher] - The launcher activity.
Gets called by [User:a1].
Creates a new ClassLoader, daisy chainging all requested APKs.
Instantiates [User:a2] w/ new ClassLoader.
Delegates all calls to [User:a2].
Resides in [JogAmp APK].
|
|
|
|
|
|
| |
boolean jnlpAlias)' for trusted properties
The method shall be called by the respective Debug specialization, which registers the trusted property prefix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PropertyAccess: Fix security code, grant access to common 'trusted' properties
- SecurityUtil
- Generalize cert validation for JAR and property access
- Grant access to common AccessControlContext for 'same' cert
- PropertyAccess:
- Fix security code: Passing the current AccessControlContext from the caller
didn't include priviledges.
- Grant access to common 'trusted' properties,
which removes the need of passing the AccessControlContext for general properties
like 'jnlp.', 'jogamp.' ..
- Enable registering 'trusted' properties, when caller's cert is 'same'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Platform, IOUtil, ..
- Intro.: PropertyAccess
- Base class of all Debug impl, reduces redundancies.
- jnlpAlias'ed trusted property is queried within local AccessControlContext
to avoid 'JRE' implementation differences (should not be required).
- throw NPE and IllegalArgumentException for invalid property key
- Added safe PropertyAccess
- JNILibLoaderBase: sun.jnlp.applet.launcher
- Platform: jogamp.gluegen.UseTempJarCache
- IOUtil: java.io.tmpdir
|
|
|
|
|
|
|
| |
- Hold DEBUG, DEBUG_LOOKUP in DynamicLookupHelper
- Tool complete only if named tool's GetProcAddressFunc is avail
- Allow no tool/glue lib's
- Use DEBUG_LOCKUP for lockup symbol trace
|
|
|
|
|
|
|
|
|
|
|
|
| |
'spawn off' process to become the lock owner.
To avoid complicated synchronization via synchronized, wait and notify between one thread
and a 'spawn' off thread which temporarly requires the hold lock,
RecursiveThreadGroupLock allows to add and remove other threads to become owners of the lock
as if they were the original holder.
This simplifies some rare locking use cases, eg. in JOGL's GLProfile initialization sequence
where a SharedResourceRunner thread is taking over initialization of shared resources.
|
|
|
|
|
|
| |
RecursiveLockImpl01Unfairish.Sync
RecursiveLockImpl01Unfairish changes are in preparation of RecursiveGroupThreadLock.
|
|
|
|
| |
private API.
|
|
|
|
| |
sizeof(long double) == 8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- RecursiveLock _is_ interface.
- Use LockFactory to create a RecursiveLock.
- Impl: RecursiveLockImpl01Unfairish
- just using notify w/o any queue: fast
- still enqueuing new lock-applicants if queue full (nice)
- lock's sync extends AbstractOwnableSynchronizer and uses it (monitor)
- Impl: RecursiveLockImpl01CompleteFair
- using queue and interrupt for correctness (slow)
- lock's sync extends AbstractOwnableSynchronizer and uses it (monitor)
- Impl: RecursiveLockImplJava5 for using Java5's concurrency impl.
- to verify correctness, performance and deviation of locking time
TestRecursiveLock01 new performance measurements incl. simple avrg and deviation
shows best combined performance-deviation w/ our RecursiveLockImpl01Unfairish
os Linux and MacOSX.
RecursiveLockImpl01Unfairish is the default in LockFactory.
Adding 'private' LockDebugUtil, allowing validating all holdings locks
of one thread as stack traces (Throwable).
Besides the AbstractOwnableSynchronizer utilization, this helps debugging deadlocks
and starvation very well.
|