What:		security/evm
Date:		March 2011
Contact:	Mimi Zohar <zohar@us.ibm.com>
Description:
		EVM protects a file's security extended attributes(xattrs)
		against integrity attacks. The initial method maintains an
		HMAC-sha1 value across the extended attributes, storing the
		value as the extended attribute 'security.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.