security/integrity/ima/ima_queue_keys.c
Source file repositories/reference/linux-study-clean/security/integrity/ima/ima_queue_keys.c
File Facts
- System
- Linux kernel
- Corpus path
security/integrity/ima/ima_queue_keys.c- Extension
.c- Size
- 4105 bytes
- Lines
- 178
- Domain
- Core OS
- Bucket
- Security And Isolation
- Inferred role
- Core OS: implementation source
- Status
- source 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.
- 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/user_namespace.hlinux/workqueue.hkeys/asymmetric-type.hima.h
Detected Declarations
function ima_keys_handlerfunction ima_init_key_queuefunction ima_free_key_entryfunction ima_queue_keyfunction ima_process_queued_keysfunction list_for_each_entry_safefunction ima_should_queue_key
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2019 Microsoft Corporation
*
* Author: Lakshmi Ramasubramanian (nramas@linux.microsoft.com)
*
* File: ima_queue_keys.c
* Enables deferred processing of keys
*/
#include <linux/user_namespace.h>
#include <linux/workqueue.h>
#include <keys/asymmetric-type.h>
#include "ima.h"
/*
* Flag to indicate whether a key can be processed
* right away or should be queued for processing later.
*/
static bool ima_process_keys;
/*
* To synchronize access to the list of keys that need to be measured
*/
static DEFINE_MUTEX(ima_keys_lock);
static LIST_HEAD(ima_keys);
/*
* If custom IMA policy is not loaded then keys queued up
* for measurement should be freed. This worker is used
* for handling this scenario.
*/
static long ima_key_queue_timeout = 300000; /* 5 Minutes */
static void ima_keys_handler(struct work_struct *work);
static DECLARE_DELAYED_WORK(ima_keys_delayed_work, ima_keys_handler);
static bool timer_expired;
/*
* This worker function frees keys that may still be
* queued up in case custom IMA policy was not loaded.
*/
static void ima_keys_handler(struct work_struct *work)
{
timer_expired = true;
ima_process_queued_keys();
}
/*
* This function sets up a worker to free queued keys in case
* custom IMA policy was never loaded.
*/
void ima_init_key_queue(void)
{
schedule_delayed_work(&ima_keys_delayed_work,
msecs_to_jiffies(ima_key_queue_timeout));
}
static void ima_free_key_entry(struct ima_key_entry *entry)
{
if (entry) {
kfree(entry->payload);
kfree(entry->keyring_name);
kfree(entry);
}
}
static struct ima_key_entry *ima_alloc_key_entry(struct key *keyring,
const void *payload,
size_t payload_len)
{
int rc = 0;
const char *audit_cause = "ENOMEM";
struct ima_key_entry *entry;
entry = kzalloc_obj(*entry);
if (entry) {
entry->payload = kmemdup(payload, payload_len, GFP_KERNEL);
entry->keyring_name = kstrdup(keyring->description,
GFP_KERNEL);
entry->payload_len = payload_len;
}
if ((entry == NULL) || (entry->payload == NULL) ||
(entry->keyring_name == NULL)) {
rc = -ENOMEM;
goto out;
}
INIT_LIST_HEAD(&entry->list);
Annotation
- Immediate include surface: `linux/user_namespace.h`, `linux/workqueue.h`, `keys/asymmetric-type.h`, `ima.h`.
- Detected declarations: `function ima_keys_handler`, `function ima_init_key_queue`, `function ima_free_key_entry`, `function ima_queue_key`, `function ima_process_queued_keys`, `function list_for_each_entry_safe`, `function ima_should_queue_key`.
- Atlas domain: Core OS / Security And Isolation.
- Implementation status: source 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.