Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751648AbdIQP2o (ORCPT ); Sun, 17 Sep 2017 11:28:44 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:35038 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751402AbdIQP2m (ORCPT ); Sun, 17 Sep 2017 11:28:42 -0400 X-Google-Smtp-Source: AOwi7QBKLPFVu8mKmwI9TzWq4BMXWSLJa/up467b4rD+LbDKOzriNqmH3cvdzfe7mkh4eurIxIh1BXKYA8vllCMwwXA= MIME-Version: 1.0 In-Reply-To: <20170917151757.GA14262@infradead.org> References: <1505451494-30228-1-git-send-email-zohar@linux.vnet.ibm.com> <1505451494-30228-4-git-send-email-zohar@linux.vnet.ibm.com> <1505507142.4200.103.camel@linux.vnet.ibm.com> <20170917151757.GA14262@infradead.org> From: Linus Torvalds Date: Sun, 17 Sep 2017 08:28:40 -0700 X-Google-Sender-Auth: GBeUiQSPbK_ERdsXSLwMoyfugoU Message-ID: Subject: Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description) To: Christoph Hellwig Cc: Mimi Zohar , LSM List , Christoph Hellwig , linux-ima-devel@lists.sourceforge.net, James Morris , Linux Kernel Mailing List , Matthew Garrett , Jan Kara , "Theodore Ts'o" , Andreas Dilger , Jaegeuk Kim , Chao Yu , Steven Whitehouse , Bob Peterson , David Woodhouse , Dave Kleikamp , Ryusuke Konishi , Mark Fasheh , Joel Becker , Richard Weinberger , "Darrick J. Wong" , Hugh Dickins , Chris Mason Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1394 Lines: 34 On Sun, Sep 17, 2017 at 8:17 AM, Christoph Hellwig wrote: > > Only for direct I/O, and IMA and direct I/O don't work together. > From ima_collect_measurement: > > if (file->f_flags & O_DIRECT) { > audit_cause = "failed(directio)"; > result = -EACCES; > goto out; > } That's not the issue. The issue is that somebody else can come in - using direct IO - at the same time as the first person is collecting measurements, and thus race with the collector. So now the measurements are not trustworthy any more. > Well, that's exactly the point of the new ->integrity_read routine > I proposed and prototype. The important thing is that it is called > with i_rwsem held because code mugh higher in the chain already > acquired it, but except for that it's entirely up to the file system. .. and *my* point is that it's the wrong lock for actually checking integrity (it doesn't actually guarantee exclusion, even though in practice it's almost always the case), and so we're adding a nasty callback that in 99% of all cases is the same as the normal read, and we *could* have just added it with a RWF flag instead. Is there some reason why integrity has to use that particular lock that is so inconvenient for the filesystems it wants to check? Linus