From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225f2y0bfBiQ543yKT7gojgrryjI6hOVsed14zXzQZ88AWblTrbdVSne4BxPScL83PN6moIZ ARC-Seal: i=1; a=rsa-sha256; t=1516969712; cv=none; d=google.com; s=arc-20160816; b=kJnjKDMD9GXzfMy0Q/4bk+gexv6oKfHnno+40UGGWjABtPX8NN6+xt28z+7MoCFeQl v2KAJDyYhBasEfcE5lU77S4eOYYA2aKV/UfrV7Fvc8Rk7CebQJJCrUbt37ArFft4Y13U xPSHotMaB8ZH4BhrRVnKJAghfMS2s6g1YZdDzX5oYphqf3ee92UBT41Xke+DQs6o5lcf pFhNwloSNv0OO0N8BhEFKvQJzh837VOEax1yJfzO5Ch24AckoOSerObYWTzMZ3YB6E/E xmKgT6N0jlzXfqNQUlRVlO4DKuUBVnqmkiJe5qZU+mleZVdCTTlYT11HO06GHXytY+FW W3nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:content-transfer-encoding:content-language:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=pUbjzLqW+NXFeUzmffI3cvEOc4IpoH102CZ7hs6p77I=; b=n6ubt/BR2si/7OX3u+exp1omB4S29+yNmbctDeLmyw5zheOv7dC6fZ+orJIXEyGG73 Ko7cs55gXGGT8KqFl7BV4+CNiqrcvOd6L4iYdvm7VNzu8CslWc59Vq+c8cmULUuvBnlP 8npD6ypTBEOOVY1A4yRTJbtzBKJXDc73juhwtbjQP6R3in0uL/c9BWyQ0Wx9TEdZL1KS /H71d8/epTuqn2QFlXPQ5iEZH94vcdFT4Eq0My7lAqYvZqoFqwB57CL4B9TVAJRS/M9P y4IjnbjdnN7t1endgS49x4AZRJoL/CcxsKGFrYgt3usFlyOYfeFjrPprGfMpfhxKJtgU 3syw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11441-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11441-gregkh=linuxfoundation.org@lists.openwall.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11441-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11441-gregkh=linuxfoundation.org@lists.openwall.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: To: Jerome Glisse , Boris Lukashev CC: Jann Horn , Kees Cook , "Michal Hocko" , Laura Abbott , "Christoph Hellwig" , Matthew Wilcox , "Christoph Lameter" , linux-security-module , Linux-MM , kernel list , Kernel Hardening References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <6c6a3f47-fc5b-0365-4663-6908ad1fc4a7@huawei.com> <20180125153839.GA3542@redhat.com> From: Igor Stoppa Message-ID: <8eb12a75-4957-d5eb-9a14-387788728b8a@huawei.com> Date: Fri, 26 Jan 2018 14:28:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20180125153839.GA3542@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590497635371449856?= X-GMAIL-MSGID: =?utf-8?q?1590658033180627942?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 25/01/18 17:38, Jerome Glisse wrote: > On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: > > [...] > >> DMA/physmap access coupled with a knowledge of which virtual mappings >> are in the physical space should be enough for an attacker to bypass >> the gating mechanism this work imposes. Not trivial, but not >> impossible. Since there's no way to prevent that sort of access in >> current hardware (especially something like a NIC or GPU working >> independently of the CPU altogether) [...] > I am not saying that this can not happen but that we are trying our best > to avoid it. How about an opt-in verification, similar to what proposed by Boris Lukashev? When reading back the data, one could access the pointer directly and bypass the verification, or could use a function that explicitly checks the integrity of the data. Starting from an unprotected kmalloc allocation, even just turning the data into R/O is an improvement, but if one can afford the overhead of performing the verification, why not? It would still be better if the service was provided by the library, instead than implemented by individual users, I think. -- igor From mboxrd@z Thu Jan 1 00:00:00 1970 From: igor.stoppa@huawei.com (Igor Stoppa) Date: Fri, 26 Jan 2018 14:28:11 +0200 Subject: [kernel-hardening] [PATCH 4/6] Protectable Memory In-Reply-To: <20180125153839.GA3542@redhat.com> References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <6c6a3f47-fc5b-0365-4663-6908ad1fc4a7@huawei.com> <20180125153839.GA3542@redhat.com> Message-ID: <8eb12a75-4957-d5eb-9a14-387788728b8a@huawei.com> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 25/01/18 17:38, Jerome Glisse wrote: > On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: > > [...] > >> DMA/physmap access coupled with a knowledge of which virtual mappings >> are in the physical space should be enough for an attacker to bypass >> the gating mechanism this work imposes. Not trivial, but not >> impossible. Since there's no way to prevent that sort of access in >> current hardware (especially something like a NIC or GPU working >> independently of the CPU altogether) [...] > I am not saying that this can not happen but that we are trying our best > to avoid it. How about an opt-in verification, similar to what proposed by Boris Lukashev? When reading back the data, one could access the pointer directly and bypass the verification, or could use a function that explicitly checks the integrity of the data. Starting from an unprotected kmalloc allocation, even just turning the data into R/O is an improvement, but if one can afford the overhead of performing the verification, why not? It would still be better if the service was provided by the library, instead than implemented by individual users, I think. -- igor -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f70.google.com (mail-wm0-f70.google.com [74.125.82.70]) by kanga.kvack.org (Postfix) with ESMTP id 4C2676B0024 for ; Fri, 26 Jan 2018 07:28:16 -0500 (EST) Received: by mail-wm0-f70.google.com with SMTP id f76so1164835wme.0 for ; Fri, 26 Jan 2018 04:28:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com. [194.213.3.17]) by mx.google.com with ESMTPS id c92si3144904edd.246.2018.01.26.04.28.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2018 04:28:15 -0800 (PST) Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory References: <20180124175631.22925-1-igor.stoppa@huawei.com> <20180124175631.22925-5-igor.stoppa@huawei.com> <6c6a3f47-fc5b-0365-4663-6908ad1fc4a7@huawei.com> <20180125153839.GA3542@redhat.com> From: Igor Stoppa Message-ID: <8eb12a75-4957-d5eb-9a14-387788728b8a@huawei.com> Date: Fri, 26 Jan 2018 14:28:11 +0200 MIME-Version: 1.0 In-Reply-To: <20180125153839.GA3542@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jerome Glisse , Boris Lukashev Cc: Jann Horn , Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , Matthew Wilcox , Christoph Lameter , linux-security-module , Linux-MM , kernel list , Kernel Hardening On 25/01/18 17:38, Jerome Glisse wrote: > On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote: >> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa wrote: > > [...] > >> DMA/physmap access coupled with a knowledge of which virtual mappings >> are in the physical space should be enough for an attacker to bypass >> the gating mechanism this work imposes. Not trivial, but not >> impossible. Since there's no way to prevent that sort of access in >> current hardware (especially something like a NIC or GPU working >> independently of the CPU altogether) [...] > I am not saying that this can not happen but that we are trying our best > to avoid it. How about an opt-in verification, similar to what proposed by Boris Lukashev? When reading back the data, one could access the pointer directly and bypass the verification, or could use a function that explicitly checks the integrity of the data. Starting from an unprotected kmalloc allocation, even just turning the data into R/O is an improvement, but if one can afford the overhead of performing the verification, why not? It would still be better if the service was provided by the library, instead than implemented by individual users, I think. -- igor -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org