Searched full:key (Results 1 – 25 of 437) sorted by relevance
12345678910>>...18
| /Documentation/security/keys/ |
| D | request-key.rst | 2 Key Request Service
5 The key request service is part of the key retention service (refer to
12 struct key *request_key(const struct key_type *type,
18 struct key *request_key_tag(const struct key_type *type,
25 struct key *request_key_with_auxdata(const struct key_type *type,
34 struct key *request_key_rcu(const struct key_type *type,
46 does not need to link the key to a keyring to prevent it from being immediately
47 destroyed. The kernel interface returns a pointer directly to the key, and
48 it's up to the caller to destroy the key.
56 NULL). This is only useful for those key types that define their own upcall
[all …]
|
| D | core.rst | 2 Kernel Key Retention Service
9 Keyrings are permitted; these are a special type of key that can hold links to
13 The key service can be configured on by enabling:
15 "Security options"/"Enable access key retention support" (CONFIG_KEYS)
22 Key Overview
26 tokens, keyrings, etc.. These are represented in the kernel by struct key.
28 Each key has a number of attributes:
32 - A description (for matching a key in a search).
39 * Each key is issued a serial number of type key_serial_t that is unique for
40 the lifetime of that key. All serial numbers are positive non-zero 32-bit
[all …]
|
| D | trusted-encrypted.rst | 5 Trusted and Encrypted Keys are two new key types added to the existing kernel
6 key ring service. Both of these new types are variable length symmetric keys,
30 Rooted to Storage Root Key (SRK) which never leaves the TPM that
35 Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
41 mode, trust is rooted to the OTPMK, a never-disclosed 256-bit key
43 Otherwise, a common fixed test key is used instead.
47 Rooted to a one-time programmable key (OTP) that is generally burnt
49 DCP provides two keys that can be used as root of trust: the OTP key
50 and the UNIQUE key. Default is to use the UNIQUE key, but selecting
51 the OTP key can be done via a module parameter (dcp_use_otp_key).
[all …]
|
| D | ecryptfs.rst | 6 file using a randomly generated File Encryption Key (FEK).
8 Each FEK is in turn encrypted with a File Encryption Key Encryption Key (FEKEK)
11 using a key, the FEKEK, derived from a user prompted passphrase; in the latter
13 to support other mechanisms like public key cryptography, PKCS#11 and TPM based
18 kernel key of the 'user' type, inserted in the user's session specific keyring
22 The 'encrypted' key type has been extended with the introduction of the new
26 kernel and protected by the parent master key.
34 required key can be securely generated by an Administrator and provided at boot
35 time after the unsealing of a 'trusted' key in order to perform the mount in a
36 controlled environment. Another advantage is that the key is not exposed to
[all …]
|
| /Documentation/crypto/ |
| D | asymmetric-keys.rst | 4 Asymmetric / Public-key Cryptography Key Type
10 - Key identification.
13 - Asymmetric key subtypes.
21 The "asymmetric" key type is designed to be a container for the keys used in
22 public-key cryptography, without imposing any particular restrictions on the
23 form or mechanism of the cryptography or form of the key.
25 The asymmetric key is given a subtype that defines what sort of data is
26 associated with the key and provides operations to describe and destroy it.
27 However, no requirement is made that the key data actually be stored in the
28 key.
[all …]
|
| /Documentation/devicetree/bindings/input/ |
| D | pxa27x-keypad.txt | 7 - marvell,debounce-interval : How long time the key will be
9 is debounce interval for direct key and bit[15:0] is debounce
10 interval for matrix key. The value is in binary number of 2ms
16 - marvell,direct-key-count : How many direct keyes are used.
17 - marvell,direct-key-mask : The mask indicates which keyes
18 are used. If bit[X] of the mask is set, the direct key X
20 - marvell,direct-key-low-active : Direct key status register
23 is low, the key is pressed(active).
24 - marvell,direct-key-map : It is a u16 array. Each item indicates
25 the linux key-code for the direct key.
[all …]
|
| D | gpio-keys.yaml | 26 …"^(button|event|key|switch|(button|event|key|switch)-[a-z0-9-]+|[a-z0-9-]+-(button|event|key|switc…
36 - description: Optional key interrupt or wakeup interrupt
38 - description: Key interrupt
53 description: Descriptive name of the key.
56 description: Key / Axis code to emit.
87 Specifies whether the key should wake the system when asserted, when
159 key-up {
160 label = "GPIO Key UP";
165 key-down {
166 label = "GPIO Key DOWN";
[all …]
|
| D | matrix-keymap.yaml | 7 title: Common Key Matrices on Matrix-connected Key Boards
13 A simple common binding for matrix-connected key boards. Currently targeted at
14 defining the keys in the scope of linux key codes since that is a stable and
18 cases where there is a modifier key such as a Fn key. Proposed names
27 column and linux key-code. The 32-bit big endian cell is packed as:
28 row << 24 | column << 16 | key-code
|
| /Documentation/driver-api/nvdimm/ |
| D | security.rst | 29 disable <keyid> - disable enabled security and remove key.
31 erase <keyid> - delete existing user encryption key.
34 master_erase <keyid> - delete existing user encryption key.
36 3. Key Management
39 The key is associated to the payload by the DIMM id. For example:
42 The DIMM id would be provided along with the key payload (passphrase) to
45 The security keys are managed on the basis of a single key per DIMM. The
46 key "passphrase" is expected to be 32bytes long. This is similar to the ATA
47 security specification [2]. A key is initially acquired via the request_key()
51 A nvdimm encrypted-key of format enc32 has the description format of:
[all …]
|
| /Documentation/security/ |
| D | siphash.rst | 13 SipHash takes a secret key filled with randomly generated numbers and either
18 Generating a key
24 siphash_key_t key;
25 get_random_bytes(&key, sizeof(key));
27 If you're not deriving your key from here, you're doing it wrong.
35 u64 siphash(const void *data, size_t len, const siphash_key_t *key);
39 u64 siphash_1u64(u64, const siphash_key_t *key);
40 u64 siphash_2u64(u64, u64, const siphash_key_t *key);
41 u64 siphash_3u64(u64, u64, u64, const siphash_key_t *key);
42 u64 siphash_4u64(u64, u64, u64, u64, const siphash_key_t *key);
[all …]
|
| D | digsig.rst | 27 Public key and signature consist of header and MPIs::
30 uint8_t version; /* key format version */
31 time_t timestamp; /* key made, always 0 for now */
47 keyid equals to SHA1[12-19] over the total key content.
49 Such approach insures that key or signature header could not be changed.
58 digsig_verify() - digital signature verification with public key
62 * digsig_verify() - digital signature verification with public key
63 * @keyring: keyring to search key in
75 int digsig_verify(struct key *keyring, const char *sig, int siglen,
81 The signing and key management utilities evm-utils provide functionality
[all …]
|
| /Documentation/admin-guide/nfs/ |
| D | nfs-idmapper.rst | 8 ways NFS could obtain this information: placing a call to /sbin/request-key
11 NFS will attempt to call /sbin/request-key first. If this succeeds, the
12 result will be cached using the generic request-key cache. This call should
13 only fail if /etc/request-key.conf is not configured for the id_resolver key
14 type, see the "Configuring" section below if you wish to use the request-key
17 If the call to /sbin/request-key fails (if /etc/request-key.conf is not
18 configured with the id_resolver key type), then the idmapper will ask the
26 The file /etc/request-key.conf will need to be modified so /sbin/request-key can
35 The last parameter, 600, defines how many seconds into the future the key will
39 id mapper uses for key descriptions::
[all …]
|
| /Documentation/admin-guide/ |
| D | bootconfig.rst | 15 additional key-value data when booting the kernel in an efficient way.
16 This allows administrators to pass a structured-Key config file.
21 The boot config syntax is a simple structured key-value. Each key consists
22 of dot-connected-words, and key and value are connected by ``=``. The value
26 KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
30 Each key word must contain only alphabets, numbers, dash (``-``) or underscore
39 There can be a key which doesn't have value or has an empty value. Those keys
40 are used for checking if the key exists or not (like a boolean).
42 Key-Value Syntax
62 In both styles, same key words are automatically merged when parsing it
[all …]
|
| D | module-signing.rst | 14 .. - Administering/protecting the private key.
24 or modules signed with an invalid key. Module signing increases security by
32 public key signing standard (though it is pluggable and permits others to be
53 signature for which the key is not known or a module that is unsigned.
55 If this is off (ie. "permissive"), then modules for which the key is not
61 signature that can be verified by a public key in the kernel's possession
97 (4) :menuselection:`File name or PKCS#11 URI of module signing key`
102 and allow the kernel modules to be signed with a key of your choosing.
103 The string provided should identify a file containing both a private key
107 certificate and a private key.
[all …]
|
| D | sysrq.rst | 1 Linux Magic System Request Key Hacks
6 What is the magic SysRq key?
9 It is a 'magical' key combo you can hit which the kernel will respond to
12 How do I enable the magic SysRq key?
15 You need to say "yes" to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when
18 the SysRq key. The default value in this file is set by the
48 How do I use the magic SysRq key?
52 You press the key combo :kbd:`ALT-SysRq-<command key>`.
56 keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is
57 also known as the 'Print Screen' key. Also some keyboards cannot
[all …]
|
| /Documentation/filesystems/ |
| D | fscrypt.rst | 18 `fscryptctl <https://github.com/google/fscryptctl>`_ or `Android's key
46 userspace provides the key, all regular files, directories, and
56 Provided that userspace chooses a strong encryption key, fscrypt
89 After an encryption key has been added, fscrypt does not hide the
94 (For the reasoning behind this, understand that while the key is
115 encryption key from kernel memory. If it does so, it will also try to
116 evict all cached inodes which had been "unlocked" using the key,
124 encrypted files and directories before removing a master key, as
128 - The kernel cannot magically wipe copies of the master key(s) that
130 copies of the master key(s) it makes as well; normally this should
[all …]
|
| /Documentation/security/tpm/ |
| D | tpm-security.rst | 70 Certain information passing in and out of the TPM, such as key sealing
71 and private key import and random number generation, is vulnerable to
89 elliptic curve key from the null seed using the standard storage seed
94 salted with the derived key will fail if the TPM is reset and the seed
98 we have to create and read the initial public key which could, of
100 However, the TPM has a key certification mechanism (using the EK
101 endorsement certificate, creating an attestation identity key and
102 certifying the null seed primary with that key) which is too complex
103 to run within the kernel, so we keep a copy of the null primary key
106 that if the null primary key certifies correctly, you know all your
[all …]
|
| /Documentation/process/ |
| D | maintainer-pgp-guide.rst | 81 of caching the private key passphrase. There are two options you should
84 - ``default-cache-ttl`` (seconds): If you use the same key again before
88 the key since initial passphrase entry, if the maximum time-to-live
108 Protect your PGP key
111 This guide assumes that you already have a PGP key that you use for Linux
116 You should also make a new key if your current one is weaker than 2048
122 A PGP key rarely consists of a single keypair -- usually it is a
125 PGP defines four capabilities that a key can have:
132 The key with the **[C]** capability is often called the "master" key,
134 key can be used in place of any of other subkey on the same chain (like
[all …]
|
| /Documentation/block/ |
| D | inline-encryption.rst | 15 in terms of key, algorithm, data unit size (the granularity of en/decryption),
20 hardware instead has a fixed number of "keyslots" and requires that the key,
34 provides fine-grained control of encryption, including the choice of key and
64 key for every I/O request, but rather keep track of which keys are in the
79 We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
80 how it will be used. This includes the type of the key (standard or
81 hardware-wrapped); the actual bytes of the key; the size of the key; the
82 algorithm and data unit size the key will be used with; and the number of bytes
83 needed to represent the maximum data unit number the key will be used with.
111 that already contains the key if possible. Otherwise it waits for an idle
[all …]
|
| D | pr.rst | 34 Only initiators with a registered key can write to the device,
38 Only initiators with a registered key can access the device.
42 Only initiators with a registered key can write to the device,
44 All initiators with a registered key are considered reservation
50 Only initiators with a registered key can access the device.
51 All initiators with a registered key are considered reservation
66 the old reservation key.
76 devices based on the type argument. The key argument must be the existing
77 reservation key for the device as acquired by the IOC_PR_REGISTER,
84 This ioctl command releases the reservation specified by key and flags
[all …]
|
| /Documentation/networking/ |
| D | dns_resolver.rst | 21 by way of requesting a key of key type dns_resolver. These queries are
22 upcalled to userspace through /sbin/request-key.
25 request-key. It is under development and does not yet provide the full feature
48 To set up this facility, the /etc/request-key.conf file must be altered so that
49 /sbin/request-key can appropriately direct the upcalls. For example, to handle
79 may then be cached. The key description is constructed as a string of the
121 The dns_resolver module registers a key type called "dns_resolver". Keys of
129 directed by means of configuration lines in /etc/request-key.conf that tell
130 /sbin/request-key what program to run to instantiate the key.
136 remainder of the string to the key as its payload.
[all …]
|
| D | openvswitch.rst | 22 extracting its flow key and looking it up in the flow table. If there
29 Flow key compatibility
35 versions to parse additional protocols as part of the flow key. It
39 applications to work with any version of the flow key, past or future.
43 flow key that it parsed from the packet. Userspace then extracts its
44 own notion of a flow key from the packet and compares it against the
47 - If userspace's notion of the flow key for the packet matches the
50 - If the kernel's flow key includes more fields than the userspace
51 version of the flow key, for example if the kernel decoded IPv6
55 as long as it uses the kernel-provided flow key to do it.
[all …]
|
| /Documentation/RCU/ |
| D | rculist_nulls.rst | 29 unsigned int key;
39 obj = lockless_lookup(key);
48 * must check key after getting the reference on object
50 if (obj->key != key) { // not the object we expected
58 Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu()
63 lockless_lookup(key)
70 if (obj->key == key)
82 if (obj->key == key)
95 checking the key."
101 and previous value of 'obj->key'. Otherwise, an item could be deleted
[all …]
|
| /Documentation/netlink/specs/ |
| D | ovs_flow.yaml | 37 name: ovs-key-ethernet
51 name: ovs-key-mpls
59 name: ovs-key-ipv4
86 name: ovs-key-ipv6
118 name: ovs-key-ipv6-exthdrs
143 name: ovs-key-tcp
155 name: ovs-key-udp
167 name: ovs-key-sctp
179 name: ovs-key-icmp
189 name: ovs-key-arp
[all …]
|
| /Documentation/bpf/ |
| D | map_hash.rst | 16 purpose hash map storage. Both the key and the value can be structs,
19 The kernel is responsible for allocating and freeing key/value pairs, up
55 long bpf_map_update_elem(struct bpf_map *map, const void *key, const void *value, u64 flags)
74 void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
78 ``key``, or ``NULL`` if no entry was found.
85 long bpf_map_delete_elem(struct bpf_map *map, const void *key)
103 void *bpf_map_lookup_percpu_elem(struct bpf_map *map, const void *key, u32 cpu)
107 ``key`` on ``cpu`` , or ``NULL`` if no entry was found or ``cpu`` is
129 libbpf's ``bpf_map_get_next_key()`` function. The first key can be fetched by
131 ``NULL``. Subsequent calls will fetch the next key that follows the
[all …]
|
12345678910>>...18