| KBIND(2) | System Calls Manual | KBIND(2) |
kbind — update
protected memory for lazy-binding
#include
<sys/unistd.h>
struct __kbind {
void *kb_addr;
size_t kb_size;
};
#define KBIND_BLOCK_MAX 2 /* powerpc and sparc64 need 2 blocks */
#define KBIND_DATA_MAX 24 /* sparc64 needs 6, four-byte words */
int
kbind(const
struct __kbind *param,
size_t psize,
int64_t cookie);
The kbind syscall updates the contents of
one or more blocks of the process's memory with the supplied replacement
data. This is used to efficiently and securely perform lazy-binding.
param points to an array of
__kbind structures giving the addresses and lengths to
update. The last __kbind structure is immediately
followed in the same order by the source data for the blocks to copy.
psize specifies the total length of the parameters:
both the __kbind structures and the associated source
data. There may be at most KBIND_BLOCK_MAX
__kbind structures and each block may be at most
KBIND_DATA_MAX bytes in size.
kbind updates memory “as if”
the thread temporarily made the memory writable with
mprotect(2). If the process does not have write access to
the underlying memory object, kbind will fail
without making the requested change.
kbind is currently intended for use by
ld.so(1) only. It is therefore not provided as a function
and two security checks are performed to bind it (pun intended) to its use
in ld.so(1): the first time kbind
is used, the kernel records both the text address of the call and the value
of the cookie argument. If those values differ in a
later kbind call, then the process is killed.
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error.
kbind() will fail if:
ENOMEM]EINVAL]kbind
limits.EFAULT]The kbind syscall is specific to the
OpenBSD dynamic linker and should not be used in
portable applications.
The kbind syscall appeared in
OpenBSD 5.8.
| November 21, 2021 | Debian |