Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2389299pxa; Mon, 3 Aug 2020 15:08:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMQC+QuPJplHwQ35o/nECDa1BzPkSvwIHj9x4SCRphqDlJv0JFgYyXXzBuQT/ZlPswxT/3 X-Received: by 2002:a05:6402:b26:: with SMTP id bo6mr17920129edb.104.1596492516965; Mon, 03 Aug 2020 15:08:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596492516; cv=none; d=google.com; s=arc-20160816; b=ZEH1UjzSfqhGQMJ4b2SNP/BlLwyt5S5TQEzYj5p+9sG76nCi4eHPbwZumsjy4Rqc8c 3JqaU2ur/HnFv7GsXRlYn7DvvqgZRu/tuYeoBk/eQpDdXSe1UReSqaKmnyRkEMvO/Wih do16vlr87Z3DROXJ9PvAMNdntoyuthBcxei4l3WC3cLoXAKJhX09WwTQp5UHfhRH0VuN YXemUMPZBb6N08eF4phknmRee3uFjvcjSq7BcElPK31mfgnGNbr62whlXX2YktskqQP7 Uu7CAmWxYcvu/FXXa1qZCe+m2Pyv1VyxcuOwpUs2GGEtqJjL6Q02uZWU0WDFa51p570S AORg== 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=lOuSme48DtaAahlNbilkFH/6Rv176zUXrsFgRlysqqs=; b=xdKyN5Cu+uakYeSfAqc7RfxHLCoavR/nXGpgBvAVlfo7UW4cypyCXHWYFpgccVOl/S 1HihenMjX7S6ZXK8r5wQ9FELakVjtk5q00GVpi3hJ6R7BwlP+wXOrwvxKMkpJgUxLTPK oXTQizcOxpmhGfpDs8hwP5qdLDwkVtNXvd36gALScLtfOe0mpwGu4AaWOFlik2ZwJfb4 2Wt+ruorzz01qb9JUy6tcC1Y0LQe7S1PC7HzX0yWCAyVdoZcq3RxzvsmACzL34ghwF1s g6dD0pDoHNBuiaKMoowYRGcom6Hfz1dGT/r5toQT3S0wmv4zubTfys0tRfvoZ+zY8T5X 6M2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=WYjnd6dI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id x6si11175923edr.497.2020.08.03.15.08.14; Mon, 03 Aug 2020 15:08:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=WYjnd6dI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1729489AbgHCWIK (ORCPT + 99 others); Mon, 3 Aug 2020 18:08:10 -0400 Received: from linux.microsoft.com ([13.77.154.182]:60894 "EHLO linux.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728708AbgHCWIK (ORCPT ); Mon, 3 Aug 2020 18:08:10 -0400 Received: from [192.168.0.104] (c-73-42-176-67.hsd1.wa.comcast.net [73.42.176.67]) by linux.microsoft.com (Postfix) with ESMTPSA id 3F70520B4908; Mon, 3 Aug 2020 15:08:09 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3F70520B4908 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1596492489; bh=lOuSme48DtaAahlNbilkFH/6Rv176zUXrsFgRlysqqs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WYjnd6dI4uoxBT0ptGFkjCRUWPUHavtt0YrQ+lPKDy6IEvcbD5UPs8HJ3W6vikKvE TiEHmYJcr9dIdemFW9y/E4Z45wzY7Fcf1YQc1I/0SA/teBekYShIVQOvFhhLfizxUE bX0N0toB9j6tQQ4f1YHNrFtNkSQ/72Ghl9PWNFJw= Subject: Re: [PATCH v5 3/4] LSM: Define SELinux function to measure state and policy To: Stephen Smalley Cc: Mimi Zohar , Casey Schaufler , Tyler Hicks , sashal@kernel.org, James Morris , linux-integrity@vger.kernel.org, SElinux list , LSM List , linux-kernel References: <20200730034724.3298-1-nramas@linux.microsoft.com> <20200730034724.3298-4-nramas@linux.microsoft.com> <6371efa9-5ae6-05ac-c357-3fbe1a5a93d5@linux.microsoft.com> <5c843a3d-713c-e71f-8d4f-c6e5f51422f1@gmail.com> From: Lakshmi Ramasubramanian Message-ID: <3e766eed-7a0b-afca-6139-ac43dea053d7@linux.microsoft.com> Date: Mon, 3 Aug 2020 15:08:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5c843a3d-713c-e71f-8d4f-c6e5f51422f1@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 8/3/20 2:07 PM, Stephen Smalley wrote: >>>> [   68.870715] irq event stamp: 23486085 >>>> [   68.870715] hardirqs last  enabled at (23486085): >>>> [] _raw_spin_unlock_irqrestore+0x46/0x60 >>>> [   68.870715] hardirqs last disabled at (23486084): >>>> [] _raw_spin_lock_irqsave+0x23/0x90 >>>> [   68.870715] softirqs last  enabled at (23486074): >>>> [] __do_softirq+0x4f3/0x662 >>>> [   68.870715] softirqs last disabled at (23486067): >>>> [] asm_call_on_stack+0x12/0x20 >>>> [   68.870715] ---[ end trace fb02740ff6f4d0cd ]--- >>> >>> I think one issue here is that systemd loads SELinux policy first, >>> then IMA policy, so it doesn't know whether it needs to measure >>> SELinux policy on first policy load, and another issue is that the >>> policy is too large to just queue the policy data itself this way (or >>> you need to use an allocator that can handle larger sizes). >>> >> >> The problem seems to be that a lock is held when the IMA hook to >> measure the LSM state is called. So memory allocation is not allowed, >> but the hook is doing an allocation. I'll address this - thanks for >> catching it. >> >> I have the following CONFIGs enabled, but I still don't see the above >> issue on my machine. >> > The warning has to do with the memory allocation order being above the > max order supported for kmalloc.  I think the problem is that > ima_alloc_data_entry() is using kmemdup() to duplicate a payload of > arbitrary size.  Policies on e.g. Fedora can be quite large, so you > can't assume they can be allocated with kmalloc and friends. > Thanks for clarifying. Yes ima_alloc_entry() does use kmemdup to save the given buffer (to be measured) until IMA loads custom policy. On my machine the SELinux policy size is about 2MB. Perhaps vmalloc would be better than using kmalloc? If there are better options for such large buffer allocation, please let me know. -lakshmi