From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226YU9fIAbbG+nv1ZoNT1Tuo6H3fV+/fw9j+5O/BiF4wjAL12nD8mRFtP5AQzrPWwPAnLuqQ ARC-Seal: i=1; a=rsa-sha256; t=1516894744; cv=none; d=google.com; s=arc-20160816; b=i4Bq9gaLXhuw5hyvPYTYpQxfpztZ2P9WK2M1IACxAwOX63U5GuQ1JSN+l83A8V0FdV xKzZBfe2mtqhGwbtWDIWlJKAZlYe6nZVEXqWLOTQCHsLSBWztZq15iDAYRA6y8DmrUSU OZ8MTbaZnRt/iitWrVzM58qY86ufqGkZvjfb2ISsiYWVnsXE93TM0HNJT51eksA8pKpO IzMHOIQ5wG2Id+SgaZb3nwDKGnVI9ZsBeQ39LVIGeTmlKYIa4mO7limLj71DuTkYsYBH MBKCXAtGNyaZIBKLqaUNDu7V0rYujV284wISr8NHhINjLFSjhvWkbPYgm4FEEsbhUH/j GVFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:cc:to:from :date:delivered-to:list-id:list-subscribe:list-unsubscribe:list-help :list-post:precedence:mailing-list:arc-authentication-results; bh=UgwAnzgifTT8jv2smcBhycwGlQ9ACIrJ0/DfCKJ8IOk=; b=02SLq72RqtMemit00wEpFIZSvLpm2+K7OEJBS6o+OR2IH9pZ0JuEo9qXc1/gY50mHx V9KWKMucPGlzquY2afB9qU9LTKYudmzwaviUv7dUdJ3JSsSMcjILUpc1n6nCQMW7FA0s 70EowV0LwVcklK/4VMHQjCtbEnizYamxR9sPgR3mEksgqztdoH/tLRwlGTGIP1YiiH31 pWlBjpwFKcgifX2CVvZYiZZxqsliJCluYhUjxmoyU8SuNmj6IF6iK9dwR3pdpZ24QE8Z mqgCA04NZ1hZ9hXCQWk7Yz7S7kV0rHw2DIBAstx1WkXmcFgksTtw0LiE/vPPJDDqrQNm CtJA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11422-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11422-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of kernel-hardening-return-11422-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11422-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Date: Thu, 25 Jan 2018 10:38:39 -0500 From: Jerome Glisse To: Boris Lukashev Cc: Igor Stoppa , Jann Horn , Kees Cook , Michal Hocko , Laura Abbott , Christoph Hellwig , Matthew Wilcox , Christoph Lameter , linux-security-module , Linux-MM , kernel list , Kernel Hardening Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) 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?1590579423224633894?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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 this is impossible but this is unlikely they are several mecanisms. First you have IOMMU it has been defaulted to on by OEM for last few years (it use to be enabled only on server for virtualization). Which means that a given device only can access memory that is mapped to it through the IOMMU page table (usualy each device get their own distinct IOMMU page table). Then on device like GPU you have an MMU (no GPU without an MMU for the last 10 years or more). The MMU is under the control of the kernel driver of the GPU and for the open source driver we try hard to make sure it can not be abuse and circumvent by userspace ie we restrict userspace process to only access memory they own. I am not saying that this can not happen but that we are trying our best to avoid it. Cheers, Jérôme