Re: [PATCH v4 2/2] IMA: Call workqueue functions to measure queued keys

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/16/2019 1:37 PM, Lakshmi Ramasubramanian wrote:

On 12/16/2019 1:17 PM, James Bottomley wrote:
On Mon, 2019-12-16 at 11:20 -0800, Lakshmi Ramasubramanian wrote:
   => If the flag is false, mutex is taken and the flag is checked
again. If the flag changed from false to true between the above two
tests, that means another thread had raced to call
ima_process_queued_keys() and has  processed the queued keys. So
again, no further action is required.

This is the problem: in the race case you may still be adding keys to
the queue after the other thread has processed it. Those keys won't get
processed because the flag is now false in the post check so the
current thread won't process them either.

James


Please keep in mind that ima_queue_key() returns a boolean indicating whether or not the key was queued. This flag is set inside the lock - please see the code snippet from ima_queue_key() below:

+	mutex_lock(&ima_keys_mutex);
+	if (!ima_process_keys) {
+		list_add_tail(&entry->list, &ima_keys);
+		queued = true;
+	}
+	mutex_unlock(&ima_keys_mutex);

If ima_process_keys had changed from false to true, ima_queue_key() will not queue the key and return false to ima_post_key_create_or_update().

Code snippet in ima_post_key_create_or_update():

+	if (!ima_process_keys)
+		queued = ima_queue_key(keyring, payload, payload_len);
+
+	if (queued)
+		return;

If the "queued" is false, ima_post_key_create_or_update() will process the key immediately.

 -lakshmi



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux