Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1101746ybl; Fri, 13 Dec 2019 09:33:58 -0800 (PST) X-Google-Smtp-Source: APXvYqwF0FiK3NhURgE4pvhyUHg+sIcU9rKtulTAP0wCpL7gLppFfv0aK/wh7g6g5UZy1WrvDrsL X-Received: by 2002:a05:6830:56a:: with SMTP id f10mr15190768otc.368.1576258438171; Fri, 13 Dec 2019 09:33:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576258438; cv=none; d=google.com; s=arc-20160816; b=c8shD3t2vslMdZcxIt7h4POulS2wCsufaHsPSh3toCUSyCIbj3US30XKY8CkfWzaK3 2Tw4WJUV1eRd8yBVc8EdGRay6B3RZd63R4WiJx/B3UK/coXkAHmoL3520w44Se7BdoeD R22auZ9nN7NdL2YqkzIvohokjiVvID2icVDqjCyjOFsRJEvyfiO4+SKMotkgH2kbPtGJ 0wfY2BfnlJAlb7rkWt5mLq+2s2PLkbFiEgJqDrhpWGaUcah9cDRkXeCkp28z6uhDmcD4 n/TnPDdAob6Xu2G/FDy2HnBiS3mIeCVfn0kf+ItDYVyoBb/wqpyyS8JvcGuX52vj1uOk g3lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature:dkim-filter; bh=K8f1QxAwXDzLq4vB/wOBc1ZmhGBElxdEEuD/7WAuoGk=; b=O2nEZcHhmL0jNr8EZjl4mTZGvrP7ZnC/b8/OnJDcT8R5QLI8SqHaIgbGw4kaDSNBHn aAcZ7heVcWH91MYdaV62o+213ZgKLLtrZwiGmNK2b+DNeMEtv6E1rremgw5YlPIMLc3m tYN9asC7GToUduiNKLigIyI+fLrdk1TTft/xrtgmNYD1DmJqsCL0+gqMfwbqkBKYmGNx PwlHpZXXoU77cpUeO148DsDXUvstAXxetLXS1T2245RIgFwn7xb3hms5RNEy3kyyjL/j Qb661AX5TCSbcfwj4WvL9ag0PvTeWfvALuknkO4DpaqboTR2DAKw/6ddS0M1U23dDmii Hk/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=aDF8A9pP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n26si5484986otf.312.2019.12.13.09.33.46; Fri, 13 Dec 2019 09:33:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=aDF8A9pP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.microsoft.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728542AbfLMRbu (ORCPT + 99 others); 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