From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED51BC43441 for ; Tue, 13 Nov 2018 18:32:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC4F32082A for ; Tue, 13 Nov 2018 18:32:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC4F32082A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-integrity-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726659AbeKNEbQ (ORCPT ); Tue, 13 Nov 2018 23:31:16 -0500 Received: from lhrrgout.huawei.com ([185.176.76.210]:32759 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726459AbeKNEbQ (ORCPT ); Tue, 13 Nov 2018 23:31:16 -0500 Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5241EDB0BEC85; Tue, 13 Nov 2018 18:31:54 +0000 (GMT) Received: from [10.202.210.149] (10.202.210.149) by smtpsuk.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 13 Nov 2018 18:31:54 +0000 Subject: Re: [PATCH 10/17] prmem: documentation To: Andy Lutomirski , Nadav Amit CC: Igor Stoppa , Kees Cook , Peter Zijlstra , Mimi Zohar , Matthew Wilcox , Dave Chinner , James Morris , Michal Hocko , "Kernel Hardening" , linux-integrity , LSM List , Dave Hansen , Jonathan Corbet , Laura Abbott , Randy Dunlap , Mike Rapoport , "open list:DOCUMENTATION" , LKML , "Thomas Gleixner" References: <20181023213504.28905-1-igor.stoppa@huawei.com> <20181023213504.28905-11-igor.stoppa@huawei.com> <20181026092609.GB3159@worktop.c.hoisthospitality.com> <20181028183126.GB744@hirez.programming.kicks-ass.net> <40cd77ce-f234-3213-f3cb-0c3137c5e201@gmail.com> <20181030152641.GE8177@hirez.programming.kicks-ass.net> <0A7AFB50-9ADE-4E12-B541-EC7839223B65@amacapital.net> <6f60afc9-0fed-7f95-a11a-9a2eef33094c@gmail.com> <386C0CB1-C4B1-43E2-A754-DA8DBE4FB3CB@gmail.com> From: Igor Stoppa Message-ID: <9373ccf0-f51b-4bfa-2b16-e03ebf3c670d@huawei.com> Date: Tue, 13 Nov 2018 20:31:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.210.149] X-CFilter-Loop: Reflected Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On 13/11/2018 19:47, Andy Lutomirski wrote: > For general rare-writish stuff, I don't think we want IRQs running > with them mapped anywhere for write. For AVC and IMA, I'm less sure. Why would these be less sensitive? But I see a big difference between my initial implementation and this one. In my case, by using a shared mapping, visible to all cores, freezing the core that is performing the write would have exposed the writable mapping to a potential attack run from another core. If the mapping is private to the core performing the write, even if it is frozen, it's much harder to figure out what it had mapped and where, from another core. To access that mapping, the attack should be performed from the ISR, I think. -- igor