Skip to content

L
linux
Switch branch/tag
  1. 16 May, 2022 1 commit
  3. 15 May, 2022 1 commit
    • Aditya Garg's avatar
      efi: Do not import certificates from UEFI Secure Boot for T2 Macs · 155ca952
      Aditya Garg authored 
      On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables
at early boot to load UEFI Secure Boot certificates, a page fault occurs
in Apple firmware code and EFI runtime services are disabled with the
following logs:

[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000
WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0
(Removed some logs from here)
Call Trace:
 <TASK>
 page_fault_oops+0x4f/0x2c0
 ? search_bpf_extables+0x6b/0x80
 ? search_module_extables+0x50/0x80
 ? search_exception_tables+0x5b/0x60
 kernelmode_fixup_or_oops+0x9e/0x110
 __bad_area_nosemaphore+0x155/0x190
 bad_area_nosemaphore+0x16/0x20
 do_kern_addr_fault+0x8c/0xa0
 exc_page_fault+0xd8/0x180
 asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
 ? __efi_call+0x28/0x30
 ? switch_mm+0x20/0x30
 ? efi_call_rts+0x19a/0x8e0
 ? process_one_work+0x222/0x3f0
 ? worker_thread+0x4a/0x3d0
 ? kthread+0x17a/0x1a0
 ? process_one_work+0x3f0/0x3f0
 ? set_kthread_struct+0x40/0x40
 ? ret_from_fork+0x22/0x30
 </TASK>
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000

So we avoid reading these UEFI variables and thus prevent the crash.

Cc: stable@vger.kernel.org
Signed-off-by: default avatarAditya Garg <gargaditya08@live.com>
Reviewed-by: default avatarMimi Zohar <zohar@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      155ca952
  5. 12 May, 2022 2 commits
  7. 05 May, 2022 3 commits
    • Mimi Zohar's avatar
      ima: support fs-verity file digest based version 3 signatures · 398c42e2
      Mimi Zohar authored 
      IMA may verify a file's integrity against a "good" value stored in the
'security.ima' xattr or as an appended signature, based on policy.  When
the "good value" is stored in the xattr, the xattr may contain a file
hash or signature.  In either case, the "good" value is preceded by a
header.  The first byte of the xattr header indicates the type of data
- hash, signature - stored in the xattr.  To support storing fs-verity
signatures in the 'security.ima' xattr requires further differentiating
the fs-verity signature from the existing IMA signature.

In addition the signatures stored in 'security.ima' xattr, need to be
disambiguated.  Instead of directly signing the fs-verity digest, a new
signature format version 3 is defined as the hash of the ima_file_id
structure, which identifies the type of signature and the digest.

The IMA policy defines "which" files are to be measured, verified, and/or
audited.  For those files being verified, the policy rules indicate "how"
the file should be verified.  For example to require a file be signed,
the appraise policy rule must include the 'appraise_type' option.

	appraise_type:= [imasig] | [imasig|modsig] | [sigv3]
           where 'imasig' is the original or signature format v2 (default),
           where 'modsig' is an appended signature,
           where 'sigv3' is the signature format v3.

The policy rule must also indicate the type of digest, if not the IMA
default, by first specifying the digest type:

	digest_type:= [verity]

The following policy rule requires fsverity signatures.  The rule may be
constrained, for example based on a fsuuid or LSM label.

      appraise func=BPRM_CHECK digest_type=verity appraise_type=sigv3
Acked-by: default avatarStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      398c42e2
    • Mimi Zohar's avatar
      ima: permit fsverity's file digests in the IMA measurement list · 54f03916
      Mimi Zohar authored 
      Permit fsverity's file digest (a hash of struct fsverity_descriptor) to
be included in the IMA measurement list, based on the new measurement
policy rule 'digest_type=verity' option.

To differentiate between a regular IMA file hash from an fsverity's
file digest, use the new d-ngv2 format field included in the ima-ngv2
template.

The following policy rule requires fsverity file digests and specifies
the new 'ima-ngv2' template, which contains the new 'd-ngv2' field.  The
policy rule may be constrained, for example based on a fsuuid or LSM
label.

measure func=FILE_CHECK digest_type=verity template=ima-ngv2
Acked-by: default avatarStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      54f03916
    • Mimi Zohar's avatar
      ima: define a new template field named 'd-ngv2' and templates · 989dc725
      Mimi Zohar authored 
      In preparation to differentiate between unsigned regular IMA file
hashes and fs-verity's file digests in the IMA measurement list,
define a new template field named 'd-ngv2'.

Also define two new templates named 'ima-ngv2' and 'ima-sigv2', which
include the new 'd-ngv2' field.
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      989dc725
  9. 01 May, 2022 3 commits
    • Mimi Zohar's avatar
      fs-verity: define a function to return the integrity protected file digest · 246d9216
      Mimi Zohar authored 
      Define a function named fsverity_get_digest() to return the verity file
digest and the associated hash algorithm (enum hash_algo).

This assumes that before calling fsverity_get_digest() the file must have
been opened, which is even true for the IMA measure/appraise on file
open policy rule use case (func=FILE_CHECK).  do_open() calls vfs_open()
immediately prior to ima_file_check().
Acked-by: default avatarEric Biggers <ebiggers@google.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      246d9216
    • Mimi Zohar's avatar
      ima: use IMA default hash algorithm for integrity violations · 09091c44
      Mimi Zohar authored 
      Integrity file violations - ToM/ToU, open writers - are recorded in the IMA
measurement list, containing 0x00's in both the template data and file data
hash fields, but 0xFF's are actually extended into TPM PCRs.  Although the
original 'ima' template data field ('d') is limited to 20 bytes, the 'd-ng'
template digest field is not.

The violation file data hash template field ('d-ng') is unnecessarily hard
coded to SHA1.  Instead of simply replacing the hard coded SHA1 hash
algorithm with a larger hash algorithm, use the hash algorithm as defined
in "ima_hash_algo".  ima_hash_algo is set to either the Kconfig IMA default
hash algorithm or as defined on the boot command line (ima_hash=).

Including a non-SHA1 file data hash algorithm in the 'd-ng' field of
violations is a cosmetic change.  The template data hash field, which is
extended into the TPM PCRs, is not affected by this change and should not
affect attestation of the IMA measurement list.
Tested-by: default avatarStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      09091c44
    • Mimi Zohar's avatar
      ima: fix 'd-ng' comments and documentation · 64466462
      Mimi Zohar authored 
      Initially the 'd-ng' template field did not prefix the digest with either
"md5" or "sha1" hash algorithms.  Prior to being upstreamed this changed,
but the comments and documentation were not updated.  Fix the comments
and documentation.

Fixes: 4d7aeee7 ("ima: define new template ima-ng and template fields d-ng and n-ng")
Reported-by: default avatarEric Biggers <ebiggers@kernel.org>
Reviewed-by: default avatarStefan Berger <stefanb@linux.ibm.com>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      64466462
  11. 07 Apr, 2022 1 commit
    • GUO Zihua's avatar
      ima: remove the IMA_TEMPLATE Kconfig option · 891163ad
      GUO Zihua authored 
      The original 'ima' measurement list template contains a hash, defined
as 20 bytes, and a null terminated pathname, limited to 255
characters.  Other measurement list templates permit both larger hashes
and longer pathnames.  When the "ima" template is configured as the
default, a new measurement list template (ima_template=) must be
specified before specifying a larger hash algorithm (ima_hash=) on the
boot command line.

To avoid this boot command line ordering issue, remove the legacy "ima"
template configuration option, allowing it to still be specified on the
boot command line.

The root cause of this issue is that during the processing of ima_hash,
we would try to check whether the hash algorithm is compatible with the
template. If the template is not set at the moment we do the check, we
check the algorithm against the configured default template. If the
default template is "ima", then we reject any hash algorithm other than
sha1 and md5.

For example, if the compiled default template is "ima", and the default
algorithm is sha1 (which is the current default). In the cmdline, we put
in "ima_hash=sha256 ima_template=ima-ng". The expected behavior would be
that ima starts with ima-ng as the template and sha256 as the hash
algorithm. However, during the processing of "ima_hash=",
"ima_template=" has not been processed yet, and hash_setup would check
the configured hash algorithm against the compiled default: ima, and
reject sha256. So at the end, the hash algorithm that is actually used
will be sha1.

With template "ima" removed from the configured default, we ensure that
the default tempalte would at least be "ima-ng" which allows for
basically any hash algorithm.

This change would not break the algorithm compatibility checks for IMA.

Fixes: 4286587d ("ima: add Kconfig default measurement list template")
Signed-off-by: default avatarGUO Zihua <guozihua@huawei.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: default avatarMimi Zohar <zohar@linux.ibm.com>
      891163ad
  13. 04 Apr, 2022 1 commit
  15. 03 Apr, 2022 8 commits
  17. 02 Apr, 2022 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7