From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 790CEC7CFCC for ; Fri, 13 Dec 2019 20:39:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A9EDD24747 for ; Fri, 13 Dec 2019 20:39:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="aDF8A9pP" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728548AbfLMRbu (ORCPT ); Fri, 13 Dec 2019 12:31:50 -0500 Received: from linux.microsoft.com ([13.77.154.182]:40174 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728109AbfLMRbu (ORCPT ); Fri, 13 Dec 2019 12:31:50 -0500 Received: from [10.137.112.108] (unknown [131.107.174.108]) by linux.microsoft.com (Postfix) with ESMTPSA id 0C6BA20B71AD; Fri, 13 Dec 2019 09:31:49 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 0C6BA20B71AD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1576258309; bh=K8f1QxAwXDzLq4vB/wOBc1ZmhGBElxdEEuD/7WAuoGk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aDF8A9pPBRvhWqxjVunYKVN/H6/GBV2B4zniutWLU6iqiAKdZpeqdBsQTQsqGPyAi jpkmp60+UPv1NEbKt8kBuNhTDIKAsRKiffGLf5cEb+E/W6lzirp+WxLfCTsgkHTz8B Qc3hsLbqJHf5es5VFTi5XXxURRHOd2TfKaTp1g3g= Subject: Re: [PATCH v4 2/2] IMA: Call workqueue functions to measure queued keys To: James Bottomley , zohar@linux.ibm.com, linux-integrity@vger.kernel.org Cc: eric.snowberg@oracle.com, dhowells@redhat.com, mathew.j.martineau@linux.intel.com, matthewgarrett@google.com, sashal@kernel.org, jamorris@linux.microsoft.com, linux-kernel@vger.kernel.org, keyrings@vger.kernel.org References: <20191213171827.28657-1-nramas@linux.microsoft.com> <20191213171827.28657-3-nramas@linux.microsoft.com> <1576257955.8504.20.camel@HansenPartnership.com> From: Lakshmi Ramasubramanian Message-ID: <39624b97-245c-ed05-27c5-588787aacc00@linux.microsoft.com> Date: Fri, 13 Dec 2019 09:31:45 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <1576257955.8504.20.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/13/19 9:25 AM, James Bottomley wrote: Hi James, > > There's no locking around the ima_process_keys flag. If you get two > policy updates in quick succession can't this flag change as you're > processing the second update meaning you lose it because the flag was > false when you decided to build it for the queue but becomes true > before you check above whether you need to queue it? > > Note you don't need locking to fix this, you just need to ensure that > you use the same copy of the flag value for both tests. > > James > Same flag (ima_process_keys) is used for making the queuing decision. Taking a lock to access ima_process_keys is required only if the flag is false. That is handled in ima_queue_key() and ima_process_queued_keys() functions. Queued keys are processed when the first policy update occurs. Subsequently, the keys are processed immediately (not queued). Could you please review those functions in this patch and let me know if you see a problem? thanks, -lakshmi