security/keys/big_key.c
Source file repositories/reference/linux-study-clean/security/keys/big_key.c
File Facts
- System
- Linux kernel
- Corpus path
security/keys/big_key.c- Extension
.c- Size
- 6709 bytes
- Lines
- 291
- 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.
- 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/init.hlinux/seq_file.hlinux/file.hlinux/shmem_fs.hlinux/err.hlinux/random.hkeys/user-type.hkeys/big_key-type.hcrypto/chacha20poly1305.h
Detected Declarations
struct big_key_payloadfunction big_key_preparsefunction big_key_free_preparsefunction big_key_revokefunction big_key_destroyfunction big_key_updatefunction big_key_describefunction big_key_readfunction big_key_init
Annotated Snippet
struct big_key_payload {
u8 *data;
struct path path;
size_t length;
};
#define to_big_key_payload(payload) \
(struct big_key_payload *)((payload).data)
/*
* If the data is under this limit, there's no point creating a shm file to
* hold it as the permanently resident metadata for the shmem fs will be at
* least as large as the data.
*/
#define BIG_KEY_FILE_THRESHOLD (sizeof(struct inode) + sizeof(struct dentry))
/*
* big_key defined keys take an arbitrary string as the description and an
* arbitrary blob of data as the payload
*/
struct key_type key_type_big_key = {
.name = "big_key",
.preparse = big_key_preparse,
.free_preparse = big_key_free_preparse,
.instantiate = generic_key_instantiate,
.revoke = big_key_revoke,
.destroy = big_key_destroy,
.describe = big_key_describe,
.read = big_key_read,
.update = big_key_update,
};
/*
* Preparse a big key
*/
int big_key_preparse(struct key_preparsed_payload *prep)
{
struct big_key_payload *payload = to_big_key_payload(prep->payload);
struct file *file;
u8 *buf, *enckey;
ssize_t written;
size_t datalen = prep->datalen;
size_t enclen = datalen + CHACHA20POLY1305_AUTHTAG_SIZE;
int ret;
BUILD_BUG_ON(sizeof(*payload) != sizeof(prep->payload.data));
if (datalen == 0 || datalen > 1024 * 1024 || !prep->data)
return -EINVAL;
/* Set an arbitrary quota */
prep->quotalen = 16;
payload->length = datalen;
if (datalen > BIG_KEY_FILE_THRESHOLD) {
/* Create a shmem file to store the data in. This will permit the data
* to be swapped out if needed.
*
* File content is stored encrypted with randomly generated key.
* Since the key is random for each file, we can set the nonce
* to zero, provided we never define a ->update() call.
*/
loff_t pos = 0;
buf = kvmalloc(enclen, GFP_KERNEL);
if (!buf)
return -ENOMEM;
/* generate random key */
enckey = kmalloc(CHACHA20POLY1305_KEY_SIZE, GFP_KERNEL);
if (!enckey) {
ret = -ENOMEM;
goto error;
}
ret = get_random_bytes_wait(enckey, CHACHA20POLY1305_KEY_SIZE);
if (unlikely(ret))
goto err_enckey;
/* encrypt data */
chacha20poly1305_encrypt(buf, prep->data, datalen, NULL, 0,
0, enckey);
/* save aligned data to file */
file = shmem_kernel_file_setup("", enclen, EMPTY_VMA_FLAGS);
if (IS_ERR(file)) {
ret = PTR_ERR(file);
goto err_enckey;
}
written = kernel_write(file, buf, enclen, &pos);
Annotation
- Immediate include surface: `linux/init.h`, `linux/seq_file.h`, `linux/file.h`, `linux/shmem_fs.h`, `linux/err.h`, `linux/random.h`, `keys/user-type.h`, `keys/big_key-type.h`.
- Detected declarations: `struct big_key_payload`, `function big_key_preparse`, `function big_key_free_preparse`, `function big_key_revoke`, `function big_key_destroy`, `function big_key_update`, `function big_key_describe`, `function big_key_read`, `function big_key_init`.
- Atlas domain: Core OS / Security And Isolation.
- Implementation status: source implementation candidate.
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.