ld_pa.1 (2010 09)

l
ld_pa(1) PA-RISC Systems Only
ld_pa(1)
Kernel Virtual Environment Support
For virtual environment support for the kernel, build your kernel with the following linker options
(instead of the -noshared option):
$
ld ... -B symbolic -b +hideallsymbols +allowrorelocs +linkersyms
...
By using these options, you create the kernel as a self-contained shared library with no exported symbols
(with the
-B symbolic, -b, and
+hideallsymbols options). Because the kernel contains references
to linker-generated symbols such as
_etext, _end, and
_edata, the +linkersyms option instructs
the linker to create these symbols (which it does not do for shared libraries by default). The kernel con-
tains direct calls and relocations in read-only data space. Normally these are applied at link time and
are fixed up to link-time virtual addresses.
In the case of relocatable kernels, the linker needs to create dynamic relocations to fix up these references
at run-time. The
+allowrorelocs
option instructs the linker to allow dynamic relocations in read-
only sections (Normally the linker issues an error message).
Security Restrictions
On a system that supports fine-grained privileges, if a process gains any privileges from the binary’s
extended attributes, dynamic path lookup is disabled. Similarly, on a system that supports compart-
ments, if a process changes compartment due to the binary’s extended attributes, the dynamic path
lookup is disabled.
See setflexsec(1M) on how to set extended attributes on a binary. See privileges (5) and compartments (5)
for more information about privileges and compartments.
Linking Secure Programs
Secure programs are programs that are commonly run by privileged users, such as
root,orprograms
that run with elevated privileges due to setuid or setgid protection. Special precautions should be
taken when linking secure programs that use shared libraries. The default linker behavior may be
sufficient for 32-bit applications, but not for 64-bit applications.
Secure 64-bit programs should be linked with the option
+noenvvar to disable the use of SHLIB_PATH
and LD_LIBRARY_PATH for locating shared library dependencies. Secure 64-bit programs should also
link with
+nodefaultrpath
to prevent the automatic construction of an embedded search path based
on search directories specified with
-L options. Most directories searched at link time don’t need to be
searched at run time, and if these directories are specified as relative paths, they expose the program to
the same security risks as the use of SHLIB_PATH and LD_LIBRARY_PATH
.
Normal programs that depend on libraries that only exist in a directory specified in
SHLIB_PATH
or
LD_LIBRARY_PATH (64-bit mode only) must be linked with
+s to enable searching SHLIB_PATH and
LD_LIBRARY_PATH. Programs that depend on
SHLIB_PATH or LD_LIBRARY_PATH cannot be pro-
tected as setuid or setgid programs.
dld uses the dynamic path lookup (with SHLIB_PATH and LD_LIBRARY_PATH
) only if the following
conditions are satisfied:
getuid() == geteuid() && getgid() == getegid()
That is, if the uid or gid does not match its effective counterpart, dld does not check the directories
specified in SHLIB_PATH and LD_LIBRARY_PATH, which causes the runtime error "library not
found".
EXTERNAL INFLUENCES
Environment Variables
The following environment variables affect the execution of
ld:
BROWSER Specifies the path name of the HTML browser to display the HP-UX Linker and
Libraries Online User’s Guide when you use the +help option.
ENABLE_PBO_FORK
By default, when an instrumented executable (see the -I option) writes the profile data,
it creates a separate process which runs in the background; and the main process exits.
If this environment variable is set to "OFF", then a separate process is not created but
the same process writes out the profile data. This is useful if you get [ETXTBSY] errors
when removing or modifying the executable after it has been executed.
HP-UX 11i Version 3: September 2010 − 19 − Hewlett-Packard Company 19