security/keys/key.c
Source file repositories/reference/linux-study-clean/security/keys/key.c
File Facts
- System
- Linux kernel
- Corpus path
security/keys/key.c- Extension
.c- Size
- 34885 bytes
- Lines
- 1294
- Domain
- Core OS
- Bucket
- Security And Isolation
- Inferred role
- Core OS: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Core operating-system implementation surface: boot, tasks, memory, VFS, syscall-facing interfaces, synchronization, credentials, and isolation.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/export.hlinux/init.hlinux/poison.hlinux/sched.hlinux/slab.hlinux/security.hlinux/workqueue.hlinux/random.hlinux/err.hinternal.h
Detected Declarations
function __key_checkfunction key_user_putfunction key_alloc_serialfunction structurefunction key_payload_reservefunction mark_key_instantiatedfunction __key_instantiate_and_linkfunction key_instantiate_and_linkfunction request_keyfunction key_putfunction key_set_timeoutfunction key_type_lookupfunction __key_updatefunction key_create_or_updatefunction key_create_or_updatefunction key_createfunction key_updatefunction key_revokefunction key_invalidatefunction generic_key_instantiatefunction register_key_typefunction unregister_key_typefunction key_initexport key_allocexport key_payload_reserveexport key_instantiate_and_linkexport key_reject_and_linkexport key_putexport key_lookupexport key_set_timeoutexport key_create_or_updateexport key_createexport key_updateexport key_revokeexport key_invalidateexport generic_key_instantiateexport register_key_typeexport unregister_key_type
Annotated Snippet
if (key->serial < 3) {
key->serial = 3;
goto attempt_insertion;
}
parent = rb_next(parent);
if (!parent)
goto attempt_insertion;
xkey = rb_entry(parent, struct key, serial_node);
if (key->serial < xkey->serial)
goto attempt_insertion;
}
}
/**
* key_alloc - Allocate a key of the specified type.
* @type: The type of key to allocate.
* @desc: The key description to allow the key to be searched out.
* @uid: The owner of the new key.
* @gid: The group ID for the new key's group permissions.
* @cred: The credentials specifying UID namespace.
* @perm: The permissions mask of the new key.
* @flags: Flags specifying quota properties.
* @restrict_link: Optional link restriction for new keyrings.
*
* Allocate a key of the specified type with the attributes given. The key is
* returned in an uninstantiated state and the caller needs to instantiate the
* key before returning.
*
* The restrict_link structure (if not NULL) will be freed when the
* keyring is destroyed, so it must be dynamically allocated.
*
* The user's key count quota is updated to reflect the creation of the key and
* the user's key data quota has the default for the key type reserved. The
* instantiation function should amend this as necessary. If insufficient
* quota is available, -EDQUOT will be returned.
*
* The LSM security modules can prevent a key being created, in which case
* -EACCES will be returned.
*
* Returns a pointer to the new key if successful and an error code otherwise.
*
* Note that the caller needs to ensure the key type isn't uninstantiated.
* Internally this can be done by locking key_types_sem. Externally, this can
* be done by either never unregistering the key type, or making sure
* key_alloc() calls don't race with module unloading.
*/
struct key *key_alloc(struct key_type *type, const char *desc,
kuid_t uid, kgid_t gid, const struct cred *cred,
key_perm_t perm, unsigned long flags,
struct key_restriction *restrict_link)
{
struct key_user *user = NULL;
struct key *key;
size_t desclen, quotalen;
int ret;
unsigned long irqflags;
key = ERR_PTR(-EINVAL);
if (!desc || !*desc)
goto error;
if (type->vet_description) {
ret = type->vet_description(desc);
if (ret < 0) {
key = ERR_PTR(ret);
goto error;
}
}
desclen = strlen(desc);
quotalen = desclen + 1 + type->def_datalen;
/* get hold of the key tracking for this user */
user = key_user_lookup(uid);
if (!user)
goto no_memory_1;
/* check that the user's quota permits allocation of another key and
* its description */
if (!(flags & KEY_ALLOC_NOT_IN_QUOTA)) {
unsigned maxkeys = uid_eq(uid, GLOBAL_ROOT_UID) ?
key_quota_root_maxkeys : key_quota_maxkeys;
unsigned maxbytes = uid_eq(uid, GLOBAL_ROOT_UID) ?
key_quota_root_maxbytes : key_quota_maxbytes;
spin_lock_irqsave(&user->lock, irqflags);
if (!(flags & KEY_ALLOC_QUOTA_OVERRUN)) {
if (user->qnkeys + 1 > maxkeys ||
Annotation
- Immediate include surface: `linux/export.h`, `linux/init.h`, `linux/poison.h`, `linux/sched.h`, `linux/slab.h`, `linux/security.h`, `linux/workqueue.h`, `linux/random.h`.
- Detected declarations: `function __key_check`, `function key_user_put`, `function key_alloc_serial`, `function structure`, `function key_payload_reserve`, `function mark_key_instantiated`, `function __key_instantiate_and_link`, `function key_instantiate_and_link`, `function request_key`, `function key_put`.
- Atlas domain: Core OS / Security And Isolation.
- Implementation status: integration implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.