<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/security/integrity, branch linux-5.17.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ima: remove the IMA_TEMPLATE Kconfig option</title>
<updated>2022-06-09T08:26:25+00:00</updated>
<author>
<name>GUO Zihua</name>
<email>guozihua@huawei.com</email>
</author>
<published>2022-04-07T02:16:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f974e3ea964f1d1555d0b32de19fabf15344a669'/>
<id>f974e3ea964f1d1555d0b32de19fabf15344a669</id>
<content type='text'>
commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream.

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: 4286587dccd43 ("ima: add Kconfig default measurement list template")
Signed-off-by: GUO Zihua &lt;guozihua@huawei.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 891163adf180bc369b2f11c9dfce6d2758d2a5bd upstream.

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: 4286587dccd43 ("ima: add Kconfig default measurement list template")
Signed-off-by: GUO Zihua &lt;guozihua@huawei.com&gt;
Cc: &lt;Stable@vger.kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi: Do not import certificates from UEFI Secure Boot for T2 Macs</title>
<updated>2022-06-09T08:26:17+00:00</updated>
<author>
<name>Aditya Garg</name>
<email>gargaditya08@live.com</email>
</author>
<published>2022-04-15T17:02:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b34786b25d75f9c119696e6bdf3827f54ae3601b'/>
<id>b34786b25d75f9c119696e6bdf3827f54ae3601b</id>
<content type='text'>
commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream.

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:
 &lt;TASK&gt;
 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
 &lt;/TASK&gt;
---[ 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: Aditya Garg &lt;gargaditya08@live.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream.

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:
 &lt;TASK&gt;
 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
 &lt;/TASK&gt;
---[ 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: Aditya Garg &lt;gargaditya08@live.com&gt;
Reviewed-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>EVM: fix the evm= __setup handler return value</title>
<updated>2022-04-08T11:57:35+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2022-02-22T21:45:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=997eaae6df0f45d8ccf08054d933753560802a33'/>
<id>997eaae6df0f45d8ccf08054d933753560802a33</id>
<content type='text'>
[ Upstream commit f2544f5e6c691679d56bb38637d2f347075b36fa ]

__setup() handlers should return 1 if the parameter is handled.
Returning 0 causes the entire string to be added to init's
environment strings (limited to 32 strings), unnecessarily polluting it.

Using the documented string "evm=fix" causes an Unknown parameter message:
  Unknown kernel command line parameters
  "BOOT_IMAGE=/boot/bzImage-517rc5 evm=fix", will be passed to user space.

and that string is added to init's environment string space:
  Run /sbin/init as init process
    with arguments:
     /sbin/init
    with environment:
     HOME=/
     TERM=linux
     BOOT_IMAGE=/boot/bzImage-517rc5
     evm=fix

With this change, using "evm=fix" acts as expected and an invalid
option ("evm=evm") causes a warning to be printed:
  evm: invalid "evm" mode
but init's environment is not polluted with this string, as expected.

Fixes: 7102ebcd65c1 ("evm: permit only valid security.evm xattrs to be updated")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reported-by: Igor Zhbanov &lt;i.zhbanov@omprussia.ru&gt;
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit f2544f5e6c691679d56bb38637d2f347075b36fa ]

__setup() handlers should return 1 if the parameter is handled.
Returning 0 causes the entire string to be added to init's
environment strings (limited to 32 strings), unnecessarily polluting it.

Using the documented string "evm=fix" causes an Unknown parameter message:
  Unknown kernel command line parameters
  "BOOT_IMAGE=/boot/bzImage-517rc5 evm=fix", will be passed to user space.

and that string is added to init's environment string space:
  Run /sbin/init as init process
    with arguments:
     /sbin/init
    with environment:
     HOME=/
     TERM=linux
     BOOT_IMAGE=/boot/bzImage-517rc5
     evm=fix

With this change, using "evm=fix" acts as expected and an invalid
option ("evm=evm") causes a warning to be printed:
  evm: invalid "evm" mode
but init's environment is not polluted with this string, as expected.

Fixes: 7102ebcd65c1 ("evm: permit only valid security.evm xattrs to be updated")
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reported-by: Igor Zhbanov &lt;i.zhbanov@omprussia.ru&gt;
Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ima: Do not print policy rule with inactive LSM labels</title>
<updated>2022-02-02T16:59:54+00:00</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2022-02-01T20:37:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=89677197ae709eb1ab3646952c44f6a171c9e74c'/>
<id>89677197ae709eb1ab3646952c44f6a171c9e74c</id>
<content type='text'>
Before printing a policy rule scan for inactive LSM labels in the policy
rule. Inactive LSM labels are identified by args_p != NULL and
rule == NULL.

Fixes: 483ec26eed42 ("ima: ima/lsm policy rule loading logic bug fixes")
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.6+
Acked-by: Christian Brauner &lt;brauner@kernel.org&gt;
[zohar@linux.ibm.com: Updated "Fixes" tag]
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before printing a policy rule scan for inactive LSM labels in the policy
rule. Inactive LSM labels are identified by args_p != NULL and
rule == NULL.

Fixes: 483ec26eed42 ("ima: ima/lsm policy rule loading logic bug fixes")
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.6+
Acked-by: Christian Brauner &lt;brauner@kernel.org&gt;
[zohar@linux.ibm.com: Updated "Fixes" tag]
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ima: Allow template selection with ima_template[_fmt]= after ima_hash=</title>
<updated>2022-02-02T16:59:54+00:00</updated>
<author>
<name>Roberto Sassu</name>
<email>roberto.sassu@huawei.com</email>
</author>
<published>2022-01-31T17:11:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bb8e52e4906f148c2faf6656b5106cf7233e9301'/>
<id>bb8e52e4906f148c2faf6656b5106cf7233e9301</id>
<content type='text'>
Commit c2426d2ad5027 ("ima: added support for new kernel cmdline parameter
ima_template_fmt") introduced an additional check on the ima_template
variable to avoid multiple template selection.

Unfortunately, ima_template could be also set by the setup function of the
ima_hash= parameter, when it calls ima_template_desc_current(). This causes
attempts to choose a new template with ima_template= or with
ima_template_fmt=, after ima_hash=, to be ignored.

Achieve the goal of the commit mentioned with the new static variable
template_setup_done, so that template selection requests after ima_hash=
are not ignored.

Finally, call ima_init_template_list(), if not already done, to initialize
the list of templates before lookup_template_desc() is called.

Reported-by: Guo Zihua &lt;guozihua@huawei.com&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Cc: stable@vger.kernel.org
Fixes: c2426d2ad5027 ("ima: added support for new kernel cmdline parameter ima_template_fmt")
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit c2426d2ad5027 ("ima: added support for new kernel cmdline parameter
ima_template_fmt") introduced an additional check on the ima_template
variable to avoid multiple template selection.

Unfortunately, ima_template could be also set by the setup function of the
ima_hash= parameter, when it calls ima_template_desc_current(). This causes
attempts to choose a new template with ima_template= or with
ima_template_fmt=, after ima_hash=, to be ignored.

Achieve the goal of the commit mentioned with the new static variable
template_setup_done, so that template selection requests after ima_hash=
are not ignored.

Finally, call ima_init_template_list(), if not already done, to initialize
the list of templates before lookup_template_desc() is called.

Reported-by: Guo Zihua &lt;guozihua@huawei.com&gt;
Signed-off-by: Roberto Sassu &lt;roberto.sassu@huawei.com&gt;
Cc: stable@vger.kernel.org
Fixes: c2426d2ad5027 ("ima: added support for new kernel cmdline parameter ima_template_fmt")
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ima: Remove ima_policy file before directory</title>
<updated>2022-02-02T16:59:09+00:00</updated>
<author>
<name>Stefan Berger</name>
<email>stefanb@linux.ibm.com</email>
</author>
<published>2022-01-25T22:46:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f7333b9572d0559e00352a926c92f29f061b4569'/>
<id>f7333b9572d0559e00352a926c92f29f061b4569</id>
<content type='text'>
The removal of ima_dir currently fails since ima_policy still exists, so
remove the ima_policy file before removing the directory.

Fixes: 4af4662fa4a9 ("integrity: IMA policy")
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The removal of ima_dir currently fails since ima_policy still exists, so
remove the ima_policy file before removing the directory.

Fixes: 4af4662fa4a9 ("integrity: IMA policy")
Signed-off-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Acked-by: Christian Brauner &lt;brauner@kernel.org&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>integrity: check the return value of audit_log_start()</title>
<updated>2022-02-02T16:44:23+00:00</updated>
<author>
<name>Xiaoke Wang</name>
<email>xkernel.wang@foxmail.com</email>
</author>
<published>2022-01-15T01:11:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=83230351c523b04ff8a029a4bdf97d881ecb96fc'/>
<id>83230351c523b04ff8a029a4bdf97d881ecb96fc</id>
<content type='text'>
audit_log_start() returns audit_buffer pointer on success or NULL on
error, so it is better to check the return value of it.

Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Signed-off-by: Xiaoke Wang &lt;xkernel.wang@foxmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
audit_log_start() returns audit_buffer pointer on success or NULL on
error, so it is better to check the return value of it.

Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider")
Signed-off-by: Xiaoke Wang &lt;xkernel.wang@foxmail.com&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Paul Moore &lt;paul@paul-moore.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ima: fix reference leak in asymmetric_verify()</title>
<updated>2022-01-24T23:37:36+00:00</updated>
<author>
<name>Eric Biggers</name>
<email>ebiggers@google.com</email>
</author>
<published>2022-01-13T19:44:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=926fd9f23b27ca6587492c3f58f4c7f4cd01dad5'/>
<id>926fd9f23b27ca6587492c3f58f4c7f4cd01dad5</id>
<content type='text'>
Don't leak a reference to the key if its algorithm is unknown.

Fixes: 947d70597236 ("ima: Support EC keys for signature verification")
Cc: &lt;stable@vger.kernel.org&gt; # v5.13+
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reviewed-by: Tianjia Zhang &lt;tianjia.zhang@linux.alibaba.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Don't leak a reference to the key if its algorithm is unknown.

Fixes: 947d70597236 ("ima: Support EC keys for signature verification")
Cc: &lt;stable@vger.kernel.org&gt; # v5.13+
Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Stefan Berger &lt;stefanb@linux.ibm.com&gt;
Reviewed-by: Tianjia Zhang &lt;tianjia.zhang@linux.alibaba.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'integrity-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity</title>
<updated>2022-01-11T21:11:10+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-01-11T21:11:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=84bfcc0b6994057905cf98d2c5cedef48b3322b5'/>
<id>84bfcc0b6994057905cf98d2c5cedef48b3322b5</id>
<content type='text'>
Pull integrity subsystem updates from Mimi Zohar:
 "The few changes are all kexec related:

   - The MOK keys are loaded onto the .platform keyring in order to
     verify the kexec kernel image signature.

     However, the MOK keys should only be trusted when secure boot is
     enabled. Before loading the MOK keys onto the .platform keyring,
     make sure the system is booted in secure boot mode.

   - When carrying the IMA measurement list across kexec, limit dumping
     the measurement list to when dynamic debug or CONFIG_DEBUG is
     enabled.

   - kselftest: add kexec_file_load selftest support for PowerNV and
     other cleanup"

* tag 'integrity-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
  selftests/kexec: Enable secureboot tests for PowerPC
  ima: silence measurement list hexdump during kexec
  selftests/kexec: update searching for the Kconfig
  selftest/kexec: fix "ignored null byte in input" warning
  integrity: Do not load MOK and MOKx when secure boot be disabled
  ima: Fix undefined arch_ima_get_secureboot() and co
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull integrity subsystem updates from Mimi Zohar:
 "The few changes are all kexec related:

   - The MOK keys are loaded onto the .platform keyring in order to
     verify the kexec kernel image signature.

     However, the MOK keys should only be trusted when secure boot is
     enabled. Before loading the MOK keys onto the .platform keyring,
     make sure the system is booted in secure boot mode.

   - When carrying the IMA measurement list across kexec, limit dumping
     the measurement list to when dynamic debug or CONFIG_DEBUG is
     enabled.

   - kselftest: add kexec_file_load selftest support for PowerNV and
     other cleanup"

* tag 'integrity-v5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
  selftests/kexec: Enable secureboot tests for PowerPC
  ima: silence measurement list hexdump during kexec
  selftests/kexec: update searching for the Kconfig
  selftest/kexec: fix "ignored null byte in input" warning
  integrity: Do not load MOK and MOKx when secure boot be disabled
  ima: Fix undefined arch_ima_get_secureboot() and co
</pre>
</div>
</content>
</entry>
<entry>
<title>ima: silence measurement list hexdump during kexec</title>
<updated>2022-01-05T11:22:00+00:00</updated>
<author>
<name>Bruno Meneguele</name>
<email>bmeneg@redhat.com</email>
</author>
<published>2021-12-29T02:03:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=520451e90cbe9da018a045825626afb354b3465c'/>
<id>520451e90cbe9da018a045825626afb354b3465c</id>
<content type='text'>
Directly calling print_hex_dump() dumps the IMA measurement list on soft
resets (kexec) straight to the syslog (kmsg/dmesg) without considering the
DEBUG flag or the dynamic debug state, causing the output to be always
printed, including during boot time.

Since this output is only valid for IMA debugging, but not necessary on
normal kexec operation, print_hex_dump_debug() adheres to the pr_debug()
behavior: the dump is only printed to syslog when DEBUG is defined or when
explicitly requested by the user through dynamic debugging.

Signed-off-by: Bruno Meneguele &lt;bmeneg@redhat.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Directly calling print_hex_dump() dumps the IMA measurement list on soft
resets (kexec) straight to the syslog (kmsg/dmesg) without considering the
DEBUG flag or the dynamic debug state, causing the output to be always
printed, including during boot time.

Since this output is only valid for IMA debugging, but not necessary on
normal kexec operation, print_hex_dump_debug() adheres to the pr_debug()
behavior: the dump is only printed to syslog when DEBUG is defined or when
explicitly requested by the user through dynamic debugging.

Signed-off-by: Bruno Meneguele &lt;bmeneg@redhat.com&gt;
Signed-off-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
