From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755856AbdIGSTh (ORCPT ); Thu, 7 Sep 2017 14:19:37 -0400 Received: from mail-it0-f49.google.com ([209.85.214.49]:43274 "EHLO mail-it0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755835AbdIGSTf (ORCPT ); Thu, 7 Sep 2017 14:19:35 -0400 X-Google-Smtp-Source: AOwi7QCaRUcDa00iGhTcA/yBVuKByO2I3jp1aF4kbUiTNGk8Co1s7svg1/GeyL+F5ZRg5veEnjVEmtvQyf8Xk9wh60s= MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Thu, 7 Sep 2017 11:19:34 -0700 X-Google-Sender-Auth: H5SJcN4OabmjtNLi9-PhiXw-lc4 Message-ID: Subject: Re: [GIT PULL] Security subsystem updates for 4.14 To: James Morris Cc: Linux Kernel Mailing List , LSM List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 4, 2017 at 3:29 AM, James Morris wrote: > > IMA: > - A new integrity_read file operation method, avoids races when > calculating file hashes Honestly, this seems really odd. It documents that it needs to be called with i_rwsem held exclusively, and even has a lockdep assert to that effect (well, not really: the code claims "exclusive", but the lockdep assert does not), but I'm not actually seeing anybody doing it. Quite the reverse, I just see integrity_read_file() doing filp_open() on the pathname and passing it to integrity_kernel_read() with no locking. It really looks like just pure garbage to me. I pulled, and I'm not unpulling the whole thing. I don't think it's been tested, and I don't think it can be right. Tell me why I'm wrong, or tell me why that garbage made it in in the first place? Linus