Merge branch 'linus' into core/objtool, to pick up dependent commits

Linas Vepstas <linas@austin.ibm.com>

Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>

Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>

Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>

Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>

Mark Brown <broonie@sirena.org.uk>

Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>

S: NL-5216 GP 's-Hertogenbosch

S: The Netherlands

N: Ashley Lai

E: ashleydlai@gmail.com

D: IBM VTPM driver

N: Savio Lam

E: lam836@cs.cuhk.hk

D: Author of the dialog utility, foundation

S: 31134 Hildesheim

S: Germany

N: Marcel Selhorst

E: tpmdd@selhorst.net

D: TPM driver

N: Darren Senn

E: sinster@darkwater.com

D: Whatever I notice needs doing (so far: itimers, /proc)

D: EISA/sysfs subsystem

S: France

# Don't add your name here, unless you really _are_ after Marc

# alphabetically. Leonard used to be very proud of being the 

# last entry, and he'll get positively pissed if he can't even

# Note: This documents additional properties of any device beyond what

# is documented in Documentation/sysfs-rules.txt

# is documented in Documentation/admin-guide/sysfs-rules.rst

What:		/sys/devices/*/of_node

Date:		February 2015

		HMAC-sha1 value across the extended attributes, storing the

		value as the extended attribute 'security.evm'.

		EVM depends on the Kernel Key Retention System to provide it

		with a trusted/encrypted key for the HMAC-sha1 operation.

		The key is loaded onto the root's keyring using keyctl.  Until

		EVM receives notification that the key has been successfully

		loaded onto the keyring (echo 1 > <securityfs>/evm), EVM

		can not create or validate the 'security.evm' xattr, but

		returns INTEGRITY_UNKNOWN.  Loading the key and signaling EVM

		should be done as early as possible.  Normally this is done

		in the initramfs, which has already been measured as part

		of the trusted boot.  For more information on creating and

		loading existing trusted/encrypted keys, refer to:

		Documentation/keys-trusted-encrypted.txt.  (A sample dracut

		patch, which loads the trusted/encrypted key and enables

		EVM, is available from http://linux-ima.sourceforge.net/#EVM.)

		EVM supports two classes of security.evm. The first is

		an HMAC-sha1 generated locally with a

		trusted/encrypted key stored in the Kernel Key

		Retention System. The second is a digital signature

		generated either locally or remotely using an

		asymmetric key. These keys are loaded onto root's

		keyring using keyctl, and EVM is then enabled by

		echoing a value to <securityfs>/evm:

		1: enable HMAC validation and creation

		2: enable digital signature validation

		3: enable HMAC and digital signature validation and HMAC

		   creation

		Further writes will be blocked if HMAC support is enabled or

		if bit 32 is set:

		echo 0x80000002 ><securityfs>/evm

		will enable digital signature validation and block

		further writes to <securityfs>/evm.

		Until this is done, EVM can not create or validate the

		'security.evm' xattr, but returns INTEGRITY_UNKNOWN.

		Loading keys and signaling EVM should be done as early

		as possible.  Normally this is done in the initramfs,

		which has already been measured as part of the trusted

		boot.  For more information on creating and loading

		existing trusted/encrypted keys, refer to:

		Documentation/security/keys/trusted-encrypted.rst. Both dracut

		(via 97masterkey and 98integrity) and systemd (via

		core/ima-setup) have support for loading keys at boot

		time.

What:		/sys/bus/mmc/devices/.../rev

Date:		October 2017

Contact:	Jin Qian <jinqian@android.com>

Description:	Extended CSD revision number