Received-SPF: pass (google.com: domain of linux-nfs+bounces-232-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <9297638a-8dab-42ba-8b60-82c03497c9cd@huaweicloud.com>
Date: Thu, 30 Nov 2023 22:34:37 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v5 23/23] integrity: Switch from rbtree to LSM-managed
 blob for integrity_iint_cache
To: Casey Schaufler <casey@schaufler-ca.com>,
 Petr Tesarik <petrtesarik@huaweicloud.com>, Paul Moore <paul@paul-moore.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, chuck.lever@oracle.com,
 jlayton@kernel.org, neilb@suse.de, kolga@netapp.com, Dai.Ngo@oracle.com,
 tom@talpey.com, jmorris@namei.org, serge@hallyn.com, zohar@linux.ibm.com,
 dmitry.kasatkin@gmail.com, dhowells@redhat.com, jarkko@kernel.org,
 stephen.smalley.work@gmail.com, eparis@parisplace.org, mic@digikod.net,
 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-nfs@vger.kernel.org, linux-security-module@vger.kernel.org,
 linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
 selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>
References: <20231107134012.682009-24-roberto.sassu@huaweicloud.com>
 <17befa132379d37977fc854a8af25f6d.paul@paul-moore.com>
 <2084adba3c27a606cbc5ed7b3214f61427a829dd.camel@huaweicloud.com>
 <CAHC9VhTTKac1o=RnQadu2xqdeKH8C_F+Wh4sY=HkGbCArwc8JQ@mail.gmail.com>
 <b6c51351be3913be197492469a13980ab379e412.camel@huaweicloud.com>
 <CAHC9VhSAryQSeFy0ZMexOiwBG-YdVGRzvh58=heH916DftcmWA@mail.gmail.com>
 <90eb8e9d-c63e-42d6-b951-f856f31590db@huaweicloud.com>
 <366a6e5f-d43d-4266-8421-a8a05938a8fd@schaufler-ca.com>
 <66ec6876-483a-4403-9baa-487ebad053f2@huaweicloud.com>
 <a121c359-03c9-42b1-aa19-1e9e34f6a386@schaufler-ca.com>
Content-Language: en-US
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
In-Reply-To: <a121c359-03c9-42b1-aa19-1e9e34f6a386@schaufler-ca.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 11/30/2023 5:15 PM, Casey Schaufler wrote:
> On 11/30/2023 12:30 AM, Petr Tesarik wrote:
>> Hi all,
>>
>> On 11/30/2023 1:41 AM, Casey Schaufler wrote:
>>> ...
>>> It would be nice if the solution directly addresses the problem.
>>> EVM needs to be after the LSMs that use xattrs, not after all LSMs.
>>> I suggested LSM_ORDER_REALLY_LAST in part to identify the notion as
>>> unattractive.
>> Excuse me to chime in, but do we really need the ordering in code?
> 
> tl;dr - Yes.
> 
>>   FWIW
>> the linker guarantees that objects appear in the order they are seen
>> during the link (unless --sort-section overrides that default, but this
>> option is not used in the kernel). Since *.a archive files are used in
>> kbuild, I have also verified that their use does not break the
>> assumption; they are always created from scratch.
>>
>> In short, to enforce an ordering, you can simply list the corresponding
>> object files in that order in the Makefile. Of course, add a big fat
>> warning comment, so people understand the order is not arbitrary.
> 
> Not everyone builds custom kernels.

Sorry, I didn't understand your comment. Everyone builds the kernel, 
also Linux distros. What Petr was suggesting was that it does not matter 
how you build the kernel, the linker will place the LSMs in the order 
they appear in the Makefile. And for this particular case, we have:

obj-$(CONFIG_IMA)                       += ima/
obj-$(CONFIG_EVM)                       += evm/

In the past, I also verified that swapping these two resulted in the 
swapped order of LSMs. Petr confirmed that it would always happen.

Thanks

Roberto