Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 78dc53c4 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 

Pull security subsystem updates from James Morris:
 "In this patchset, we finally get an SELinux update, with Paul Moore
  taking over as maintainer of that code.

  Also a significant update for the Keys subsystem, as well as
  maintenance updates to Smack, IMA, TPM, and Apparmor"

and since I wanted to know more about the updates to key handling,
here's the explanation from David Howells on that:

 "Okay.  There are a number of separate bits.  I'll go over the big bits
  and the odd important other bit, most of the smaller bits are just
  fixes and cleanups.  If you want the small bits accounting for, I can
  do that too.

   (1) Keyring capacity expansion.

        KEYS: Consolidate the concept of an 'index key' for key access
        KEYS: Introduce a search context structure
        KEYS: Search for auth-key by name rather than target key ID
        Add a generic associative array implementation.
        KEYS: Expand the capacity of a keyring

     Several of the patches are providing an expansion of the capacity of a
     keyring.  Currently, the maximum size of a keyring payload is one page.
     Subtract a small header and then divide up into pointers, that only gives
     you ~500 pointers on an x86_64 box.  However, since the NFS idmapper uses
     a keyring to store ID mapping data, that has proven to be insufficient to
     the cause.

     Whatever data structure I use to handle the keyring payload, it can only
     store pointers to keys, not the keys themselves because several keyrings
     may point to a single key.  This precludes inserting, say, and rb_node
     struct into the key struct for this purpose.

     I could make an rbtree of records such that each record has an rb_node
     and a key pointer, but that would use four words of space per key stored
     in the keyring.  It would, however, be able to use much existing code.

     I selected instead a non-rebalancing radix-tree type approach as that
     could have a better space-used/key-pointer ratio.  I could have used the
     radix tree implementation that we already have and insert keys into it by
     their serial numbers, but that means any sort of search must iterate over
     the whole radix tree.  Further, its nodes are a bit on the capacious side
     for what I want - especially given that key serial numbers are randomly
     allocated, thus leaving a lot of empty space in the tree.

     So what I have is an associative array that internally is a radix-tree
     with 16 pointers per node where the index key is constructed from the key
     type pointer and the key description.  This means that an exact lookup by
     type+description is very fast as this tells us how to navigate directly to
     the target key.

     I made the data structure general in lib/assoc_array.c as far as it is
     concerned, its index key is just a sequence of bits that leads to a
     pointer.  It's possible that someone else will be able to make use of it
     also.  FS-Cache might, for example.

   (2) Mark keys as 'trusted' and keyrings as 'trusted only'.

        KEYS: verify a certificate is signed by a 'trusted' key
        KEYS: Make the system 'trusted' keyring viewable by userspace
        KEYS: Add a 'trusted' flag and a 'trusted only' flag
        KEYS: Separate the kernel signature checking keyring from module signing

     These patches allow keys carrying asymmetric public keys to be marked as
     being 'trusted' and allow keyrings to be marked as only permitting the
     addition or linkage of trusted keys.

     Keys loaded from hardware during kernel boot or compiled into the kernel
     during build are marked as being trusted automatically.  New keys can be
     loaded at runtime with add_key().  They are checked against the system
     keyring contents and if their signatures can be validated with keys that
     are already marked trusted, then they are marked trusted also and can
     thus be added into the master keyring.

     Patches from Mimi Zohar make this usable with the IMA keyrings also.

   (3) Remove the date checks on the key used to validate a module signature.

        X.509: Remove certificate date checks

     It's not reasonable to reject a signature just because the key that it was
     generated with is no longer valid datewise - especially if the kernel
     hasn't yet managed to set the system clock when the first module is
     loaded - so just remove those checks.

   (4) Make it simpler to deal with additional X.509 being loaded into the kernel.

        KEYS: Load *.x509 files into kernel keyring
        KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate

     The builder of the kernel now just places files with the extension ".x509"
     into the kernel source or build trees and they're concatenated by the
     kernel build and stuffed into the appropriate section.

   (5) Add support for userspace kerberos to use keyrings.

        KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches
        KEYS: Implement a big key type that can save to tmpfs

     Fedora went to, by default, storing kerberos tickets and tokens in tmpfs.
     We looked at storing it in keyrings instead as that confers certain
     advantages such as tickets being automatically deleted after a certain
     amount of time and the ability for the kernel to get at these tokens more
     easily.

     To make this work, two things were needed:

     (a) A way for the tickets to persist beyond the lifetime of all a user's
         sessions so that cron-driven processes can still use them.

         The problem is that a user's session keyrings are deleted when the
         session that spawned them logs out and the user's user keyring is
         deleted when the UID is deleted (typically when the last log out
         happens), so neither of these places is suitable.

         I've added a system keyring into which a 'persistent' keyring is
         created for each UID on request.  Each time a user requests their
         persistent keyring, the expiry time on it is set anew.  If the user
         doesn't ask for it for, say, three days, the keyring is automatically
         expired and garbage collected using the existing gc.  All the kerberos
         tokens it held are then also gc'd.

     (b) A key type that can hold really big tickets (up to 1MB in size).

         The problem is that Active Directory can return huge tickets with lots
         of auxiliary data attached.  We don't, however, want to eat up huge
         tracts of unswappable kernel space for this, so if the ticket is
         greater than a certain size, we create a swappable shmem file and dump
         the contents in there and just live with the fact we then have an
         inode and a dentry overhead.  If the ticket is smaller than that, we
         slap it in a kmalloc()'d buffer"

* 'for-linus2' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (121 commits)
  KEYS: Fix keyring content gc scanner
  KEYS: Fix error handling in big_key instantiation
  KEYS: Fix UID check in keyctl_get_persistent()
  KEYS: The RSA public key algorithm needs to select MPILIB
  ima: define '_ima' as a builtin 'trusted' keyring
  ima: extend the measurement list to include the file signature
  kernel/system_certificate.S: use real contents instead of macro GLOBAL()
  KEYS: fix error return code in big_key_instantiate()
  KEYS: Fix keyring quota misaccounting on key replacement and unlink
  KEYS: Fix a race between negating a key and reading the error set
  KEYS: Make BIG_KEYS boolean
  apparmor: remove the "task" arg from may_change_ptraced_domain()
  apparmor: remove parent task info from audit logging
  apparmor: remove tsk field from the apparmor_audit_struct
  apparmor: fix capability to not use the current task, during reporting
  Smack: Ptrace access check mode
  ima: provide hash algo info in the xattr
  ima: enable support for larger default filedata hash algorithms
  ima: define kernel parameter 'ima_template=' to change configured default
  ima: add Kconfig default measurement list template
  ...
parents 3eaded86 62fe3182

Documentation/assoc_array.txt

0 → 100644
+574 −0
Original line number Original line Diff line number Diff line 
		   ========================================

		   GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION

		   ========================================



Contents:



 - Overview.



 - The public API.

   - Edit script.

   - Operations table.

   - Manipulation functions.

   - Access functions.

   - Index key form.



 - Internal workings.

   - Basic internal tree layout.

   - Shortcuts.

   - Splitting and collapsing nodes.

   - Non-recursive iteration.

   - Simultaneous alteration and iteration.





========

OVERVIEW

========



This associative array implementation is an object container with the following

properties:



 (1) Objects are opaque pointers.  The implementation does not care where they

     point (if anywhere) or what they point to (if anything).



     [!] NOTE: Pointers to objects _must_ be zero in the least significant bit.



 (2) Objects do not need to contain linkage blocks for use by the array.  This

     permits an object to be located in multiple arrays simultaneously.

     Rather, the array is made up of metadata blocks that point to objects.



 (3) Objects require index keys to locate them within the array.



 (4) Index keys must be unique.  Inserting an object with the same key as one

     already in the array will replace the old object.



 (5) Index keys can be of any length and can be of different lengths.



 (6) Index keys should encode the length early on, before any variation due to

     length is seen.



 (7) Index keys can include a hash to scatter objects throughout the array.



 (8) The array can iterated over.  The objects will not necessarily come out in

     key order.



 (9) The array can be iterated over whilst it is being modified, provided the

     RCU readlock is being held by the iterator.  Note, however, under these

     circumstances, some objects may be seen more than once.  If this is a

     problem, the iterator should lock against modification.  Objects will not

     be missed, however, unless deleted.



(10) Objects in the array can be looked up by means of their index key.



(11) Objects can be looked up whilst the array is being modified, provided the

     RCU readlock is being held by the thread doing the look up.



The implementation uses a tree of 16-pointer nodes internally that are indexed

on each level by nibbles from the index key in the same manner as in a radix

tree.  To improve memory efficiency, shortcuts can be emplaced to skip over

what would otherwise be a series of single-occupancy nodes.  Further, nodes

pack leaf object pointers into spare space in the node rather than making an

extra branch until as such time an object needs to be added to a full node.





==============

THE PUBLIC API

==============



The public API can be found in <linux/assoc_array.h>.  The associative array is

rooted on the following structure:



	struct assoc_array {

		...

	};



The code is selected by enabling CONFIG_ASSOCIATIVE_ARRAY.





EDIT SCRIPT

-----------



The insertion and deletion functions produce an 'edit script' that can later be

applied to effect the changes without risking ENOMEM.  This retains the

preallocated metadata blocks that will be installed in the internal tree and

keeps track of the metadata blocks that will be removed from the tree when the

script is applied.



This is also used to keep track of dead blocks and dead objects after the

script has been applied so that they can be freed later.  The freeing is done

after an RCU grace period has passed - thus allowing access functions to

proceed under the RCU read lock.



The script appears as outside of the API as a pointer of the type:



	struct assoc_array_edit;



There are two functions for dealing with the script:



 (1) Apply an edit script.



	void assoc_array_apply_edit(struct assoc_array_edit *edit);



     This will perform the edit functions, interpolating various write barriers

     to permit accesses under the RCU read lock to continue.  The edit script

     will then be passed to call_rcu() to free it and any dead stuff it points

     to.



 (2) Cancel an edit script.



	void assoc_array_cancel_edit(struct assoc_array_edit *edit);



     This frees the edit script and all preallocated memory immediately.  If

     this was for insertion, the new object is _not_ released by this function,

     but must rather be released by the caller.



These functions are guaranteed not to fail.





OPERATIONS TABLE

----------------



Various functions take a table of operations:



	struct assoc_array_ops {

		...

	};



This points to a number of methods, all of which need to be provided:



 (1) Get a chunk of index key from caller data:



	unsigned long (*get_key_chunk)(const void *index_key, int level);



     This should return a chunk of caller-supplied index key starting at the

     *bit* position given by the level argument.  The level argument will be a

     multiple of ASSOC_ARRAY_KEY_CHUNK_SIZE and the function should return

     ASSOC_ARRAY_KEY_CHUNK_SIZE bits.  No error is possible.





 (2) Get a chunk of an object's index key.



	unsigned long (*get_object_key_chunk)(const void *object, int level);



     As the previous function, but gets its data from an object in the array

     rather than from a caller-supplied index key.





 (3) See if this is the object we're looking for.



	bool (*compare_object)(const void *object, const void *index_key);



     Compare the object against an index key and return true if it matches and

     false if it doesn't.





 (4) Diff the index keys of two objects.



	int (*diff_objects)(const void *a, const void *b);



     Return the bit position at which the index keys of two objects differ or

     -1 if they are the same.





 (5) Free an object.



	void (*free_object)(void *object);



     Free the specified object.  Note that this may be called an RCU grace

     period after assoc_array_apply_edit() was called, so synchronize_rcu() may

     be necessary on module unloading.





MANIPULATION FUNCTIONS

----------------------



There are a number of functions for manipulating an associative array:



 (1) Initialise an associative array.



	void assoc_array_init(struct assoc_array *array);



     This initialises the base structure for an associative array.  It can't

     fail.





 (2) Insert/replace an object in an associative array.



	struct assoc_array_edit *

	assoc_array_insert(struct assoc_array *array,

			   const struct assoc_array_ops *ops,

			   const void *index_key,

			   void *object);



     This inserts the given object into the array.  Note that the least

     significant bit of the pointer must be zero as it's used to type-mark

     pointers internally.



     If an object already exists for that key then it will be replaced with the

     new object and the old one will be freed automatically.



     The index_key argument should hold index key information and is

     passed to the methods in the ops table when they are called.



     This function makes no alteration to the array itself, but rather returns

     an edit script that must be applied.  -ENOMEM is returned in the case of

     an out-of-memory error.



     The caller should lock exclusively against other modifiers of the array.





 (3) Delete an object from an associative array.



	struct assoc_array_edit *

	assoc_array_delete(struct assoc_array *array,

			   const struct assoc_array_ops *ops,

			   const void *index_key);



     This deletes an object that matches the specified data from the array.



     The index_key argument should hold index key information and is

     passed to the methods in the ops table when they are called.



     This function makes no alteration to the array itself, but rather returns

     an edit script that must be applied.  -ENOMEM is returned in the case of

     an out-of-memory error.  NULL will be returned if the specified object is

     not found within the array.



     The caller should lock exclusively against other modifiers of the array.





 (4) Delete all objects from an associative array.



	struct assoc_array_edit *

	assoc_array_clear(struct assoc_array *array,

			  const struct assoc_array_ops *ops);



     This deletes all the objects from an associative array and leaves it

     completely empty.



     This function makes no alteration to the array itself, but rather returns

     an edit script that must be applied.  -ENOMEM is returned in the case of

     an out-of-memory error.



     The caller should lock exclusively against other modifiers of the array.





 (5) Destroy an associative array, deleting all objects.



	void assoc_array_destroy(struct assoc_array *array,

				 const struct assoc_array_ops *ops);



     This destroys the contents of the associative array and leaves it

     completely empty.  It is not permitted for another thread to be traversing

     the array under the RCU read lock at the same time as this function is

     destroying it as no RCU deferral is performed on memory release -

     something that would require memory to be allocated.



     The caller should lock exclusively against other modifiers and accessors

     of the array.





 (6) Garbage collect an associative array.



	int assoc_array_gc(struct assoc_array *array,

			   const struct assoc_array_ops *ops,

			   bool (*iterator)(void *object, void *iterator_data),

			   void *iterator_data);



     This iterates over the objects in an associative array and passes each one

     to iterator().  If iterator() returns true, the object is kept.  If it

     returns false, the object will be freed.  If the iterator() function

     returns true, it must perform any appropriate refcount incrementing on the

     object before returning.



     The internal tree will be packed down if possible as part of the iteration

     to reduce the number of nodes in it.



     The iterator_data is passed directly to iterator() and is otherwise

     ignored by the function.



     The function will return 0 if successful and -ENOMEM if there wasn't

     enough memory.



     It is possible for other threads to iterate over or search the array under

     the RCU read lock whilst this function is in progress.  The caller should

     lock exclusively against other modifiers of the array.





ACCESS FUNCTIONS

----------------



There are two functions for accessing an associative array:



 (1) Iterate over all the objects in an associative array.



	int assoc_array_iterate(const struct assoc_array *array,

				int (*iterator)(const void *object,

						void *iterator_data),

				void *iterator_data);



     This passes each object in the array to the iterator callback function.

     iterator_data is private data for that function.



     This may be used on an array at the same time as the array is being

     modified, provided the RCU read lock is held.  Under such circumstances,

     it is possible for the iteration function to see some objects twice.  If

     this is a problem, then modification should be locked against.  The

     iteration algorithm should not, however, miss any objects.



     The function will return 0 if no objects were in the array or else it will

     return the result of the last iterator function called.  Iteration stops

     immediately if any call to the iteration function results in a non-zero

     return.





 (2) Find an object in an associative array.



	void *assoc_array_find(const struct assoc_array *array,

			       const struct assoc_array_ops *ops,

			       const void *index_key);



     This walks through the array's internal tree directly to the object

     specified by the index key..



     This may be used on an array at the same time as the array is being

     modified, provided the RCU read lock is held.



     The function will return the object if found (and set *_type to the object

     type) or will return NULL if the object was not found.





INDEX KEY FORM

--------------



The index key can be of any form, but since the algorithms aren't told how long

the key is, it is strongly recommended that the index key includes its length

very early on before any variation due to the length would have an effect on

comparisons.



This will cause leaves with different length keys to scatter away from each

other - and those with the same length keys to cluster together.



It is also recommended that the index key begin with a hash of the rest of the

key to maximise scattering throughout keyspace.



The better the scattering, the wider and lower the internal tree will be.



Poor scattering isn't too much of a problem as there are shortcuts and nodes

can contain mixtures of leaves and metadata pointers.



The index key is read in chunks of machine word.  Each chunk is subdivided into

one nibble (4 bits) per level, so on a 32-bit CPU this is good for 8 levels and

on a 64-bit CPU, 16 levels.  Unless the scattering is really poor, it is

unlikely that more than one word of any particular index key will have to be

used.





=================

INTERNAL WORKINGS

=================



The associative array data structure has an internal tree.  This tree is

constructed of two types of metadata blocks: nodes and shortcuts.



A node is an array of slots.  Each slot can contain one of four things:



 (*) A NULL pointer, indicating that the slot is empty.



 (*) A pointer to an object (a leaf).



 (*) A pointer to a node at the next level.



 (*) A pointer to a shortcut.





BASIC INTERNAL TREE LAYOUT

--------------------------



Ignoring shortcuts for the moment, the nodes form a multilevel tree.  The index

key space is strictly subdivided by the nodes in the tree and nodes occur on

fixed levels.  For example:



 Level:	0		1		2		3

	===============	===============	===============	===============

							NODE D

			NODE B		NODE C	+------>+---+

		+------>+---+	+------>+---+	|	| 0 |

	NODE A	|	| 0 |	|	| 0 |	|	+---+

	+---+	|	+---+	|	+---+	|	:   :

	| 0 |	|	:   :	|	:   :	|	+---+

	+---+	|	+---+	|	+---+	|	| f |

	| 1 |---+	| 3 |---+	| 7 |---+	+---+

	+---+		+---+		+---+

	:   :		:   :		| 8 |---+

	+---+		+---+		+---+	|	NODE E

	| e |---+	| f |		:   :   +------>+---+

	+---+	|	+---+		+---+		| 0 |

	| f |	|			| f |		+---+

	+---+	|			+---+		:   :

		|	NODE F				+---+

		+------>+---+				| f |

			| 0 |		NODE G		+---+

			+---+	+------>+---+

			:   :	|	| 0 |

			+---+	|	+---+

			| 6 |---+	:   :

			+---+		+---+

			:   :		| f |

			+---+		+---+

			| f |

			+---+



In the above example, there are 7 nodes (A-G), each with 16 slots (0-f).

Assuming no other meta data nodes in the tree, the key space is divided thusly:



	KEY PREFIX	NODE

	==========	====

	137*		D

	138*		E

	13[0-69-f]*	C

	1[0-24-f]*	B

	e6*		G

	e[0-57-f]*	F

	[02-df]*	A



So, for instance, keys with the following example index keys will be found in

the appropriate nodes:



	INDEX KEY	PREFIX	NODE

	===============	=======	====

	13694892892489	13	C

	13795289025897	137	D

	13889dde88793	138	E

	138bbb89003093	138	E

	1394879524789	12	C

	1458952489	1	B

	9431809de993ba	-	A

	b4542910809cd	-	A

	e5284310def98	e	F

	e68428974237	e6	G

	e7fffcbd443	e	F

	f3842239082	-	A



To save memory, if a node can hold all the leaves in its portion of keyspace,

then the node will have all those leaves in it and will not have any metadata

pointers - even if some of those leaves would like to be in the same slot.



A node can contain a heterogeneous mix of leaves and metadata pointers.

Metadata pointers must be in the slots that match their subdivisions of key

space.  The leaves can be in any slot not occupied by a metadata pointer.  It

is guaranteed that none of the leaves in a node will match a slot occupied by a

metadata pointer.  If the metadata pointer is there, any leaf whose key matches

the metadata key prefix must be in the subtree that the metadata pointer points

to.



In the above example list of index keys, node A will contain:



	SLOT	CONTENT		INDEX KEY (PREFIX)

	====	===============	==================

	1	PTR TO NODE B	1*

	any	LEAF		9431809de993ba

	any	LEAF		b4542910809cd

	e	PTR TO NODE F	e*

	any	LEAF		f3842239082



and node B:



	3	PTR TO NODE C	13*

	any	LEAF		1458952489





SHORTCUTS

---------



Shortcuts are metadata records that jump over a piece of keyspace.  A shortcut

is a replacement for a series of single-occupancy nodes ascending through the

levels.  Shortcuts exist to save memory and to speed up traversal.



It is possible for the root of the tree to be a shortcut - say, for example,

the tree contains at least 17 nodes all with key prefix '1111'.  The insertion

algorithm will insert a shortcut to skip over the '1111' keyspace in a single

bound and get to the fourth level where these actually become different.





SPLITTING AND COLLAPSING NODES

------------------------------



Each node has a maximum capacity of 16 leaves and metadata pointers.  If the

insertion algorithm finds that it is trying to insert a 17th object into a

node, that node will be split such that at least two leaves that have a common

key segment at that level end up in a separate node rooted on that slot for

that common key segment.



If the leaves in a full node and the leaf that is being inserted are

sufficiently similar, then a shortcut will be inserted into the tree.



When the number of objects in the subtree rooted at a node falls to 16 or

fewer, then the subtree will be collapsed down to a single node - and this will

ripple towards the root if possible.





NON-RECURSIVE ITERATION

-----------------------



Each node and shortcut contains a back pointer to its parent and the number of

slot in that parent that points to it.  None-recursive iteration uses these to

proceed rootwards through the tree, going to the parent node, slot N + 1 to

make sure progress is made without the need for a stack.



The backpointers, however, make simultaneous alteration and iteration tricky.





SIMULTANEOUS ALTERATION AND ITERATION

-------------------------------------



There are a number of cases to consider:



 (1) Simple insert/replace.  This involves simply replacing a NULL or old

     matching leaf pointer with the pointer to the new leaf after a barrier.

     The metadata blocks don't change otherwise.  An old leaf won't be freed

     until after the RCU grace period.



 (2) Simple delete.  This involves just clearing an old matching leaf.  The

     metadata blocks don't change otherwise.  The old leaf won't be freed until

     after the RCU grace period.



 (3) Insertion replacing part of a subtree that we haven't yet entered.  This

     may involve replacement of part of that subtree - but that won't affect

     the iteration as we won't have reached the pointer to it yet and the

     ancestry blocks are not replaced (the layout of those does not change).



 (4) Insertion replacing nodes that we're actively processing.  This isn't a

     problem as we've passed the anchoring pointer and won't switch onto the

     new layout until we follow the back pointers - at which point we've

     already examined the leaves in the replaced node (we iterate over all the

     leaves in a node before following any of its metadata pointers).



     We might, however, re-see some leaves that have been split out into a new

     branch that's in a slot further along than we were at.



 (5) Insertion replacing nodes that we're processing a dependent branch of.

     This won't affect us until we follow the back pointers.  Similar to (4).



 (6) Deletion collapsing a branch under us.  This doesn't affect us because the

     back pointers will get us back to the parent of the new node before we

     could see the new node.  The entire collapsed subtree is thrown away

     unchanged - and will still be rooted on the same slot, so we shouldn't

     process it a second time as we'll go back to slot + 1.



Note:



 (*) Under some circumstances, we need to simultaneously change the parent

     pointer and the parent slot pointer on a node (say, for example, we

     inserted another node before it and moved it up a level).  We cannot do

     this without locking against a read - so we have to replace that node too.



     However, when we're changing a shortcut into a node this isn't a problem

     as shortcuts only have one slot and so the parent slot number isn't used

     when traversing backwards over one.  This means that it's okay to change

     the slot number first - provided suitable barriers are used to make sure

     the parent slot number is read after the back pointer.



Obsolete blocks and leaves are freed up after an RCU grace period has passed,

so as long as anyone doing walking or iteration holds the RCU read lock, the

old superstructure should not go away on them.

Documentation/devicetree/bindings/i2c/trivial-devices.txt

+3 −0
Original line number Original line Diff line number Diff line
@@ -15,6 +15,7 @@ adi,adt7461 +/-1C TDM Extended Temp Range I.C 
adt7461			+/-1C TDM Extended Temp Range I.C

adt7461			+/-1C TDM Extended Temp Range I.C

at,24c08		i2c serial eeprom  (24cxx)

at,24c08		i2c serial eeprom  (24cxx)

atmel,24c02		i2c serial eeprom  (24cxx)

atmel,24c02		i2c serial eeprom  (24cxx)

atmel,at97sc3204t	i2c trusted platform module (TPM)

catalyst,24c32		i2c serial eeprom

catalyst,24c32		i2c serial eeprom

dallas,ds1307		64 x 8, Serial, I2C Real-Time Clock

dallas,ds1307		64 x 8, Serial, I2C Real-Time Clock

dallas,ds1338		I2C RTC with 56-Byte NV RAM

dallas,ds1338		I2C RTC with 56-Byte NV RAM
@@ -44,6 +45,7 @@ mc,rv3029c2 Real Time Clock Module with I2C-Bus 
national,lm75		I2C TEMP SENSOR

national,lm75		I2C TEMP SENSOR

national,lm80		Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor

national,lm80		Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor

national,lm92		±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface

national,lm92		±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface

nuvoton,npct501		i2c trusted platform module (TPM)

nxp,pca9556		Octal SMBus and I2C registered interface

nxp,pca9556		Octal SMBus and I2C registered interface

nxp,pca9557		8-bit I2C-bus and SMBus I/O port with reset

nxp,pca9557		8-bit I2C-bus and SMBus I/O port with reset

nxp,pcf8563		Real-time clock/calendar

nxp,pcf8563		Real-time clock/calendar
@@ -61,3 +63,4 @@ taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface 
ti,tsc2003		I2C Touch-Screen Controller

ti,tsc2003		I2C Touch-Screen Controller

ti,tmp102		Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface

ti,tmp102		Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface

ti,tmp275		Digital Temperature Sensor

ti,tmp275		Digital Temperature Sensor

winbond,wpct301		i2c trusted platform module (TPM)

Documentation/kernel-parameters.txt

+10 −1
Original line number Original line Diff line number Diff line
@@ -1190,15 +1190,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted. 
			owned by uid=0.

			owned by uid=0.





	ima_hash=	[IMA]

	ima_hash=	[IMA]

			Format: { "sha1" | "md5" }

			Format: { md5 | sha1 | rmd160 | sha256 | sha384

				   | sha512 | ... }

			default: "sha1"

			default: "sha1"





			The list of supported hash algorithms is defined

			in crypto/hash_info.h.



	ima_tcb		[IMA]

	ima_tcb		[IMA]

			Load a policy which meets the needs of the Trusted

			Load a policy which meets the needs of the Trusted

			Computing Base.  This means IMA will measure all

			Computing Base.  This means IMA will measure all

			programs exec'd, files mmap'd for exec, and all files

			programs exec'd, files mmap'd for exec, and all files

			opened for read by uid=0.

			opened for read by uid=0.





	ima_template=   [IMA]

			Select one of defined IMA measurements template formats.

			Formats: { "ima" | "ima-ng" }

			Default: "ima-ng"



	init=		[KNL]

	init=		[KNL]

			Format: <full_path>

			Format: <full_path>

			Run specified binary instead of /sbin/init as init

			Run specified binary instead of /sbin/init as init

Documentation/security/00-INDEX

+2 −0
Original line number Original line Diff line number Diff line
@@ -22,3 +22,5 @@ keys.txt 
	- description of the kernel key retention service.

	- description of the kernel key retention service.

tomoyo.txt

tomoyo.txt

	- documentation on the TOMOYO Linux Security Module.

	- documentation on the TOMOYO Linux Security Module.

IMA-templates.txt

	- documentation on the template management mechanism for IMA.

Documentation/security/IMA-templates.txt

0 → 100644
+87 −0

File added.

Preview size limit exceeded, changes collapsed.