From: Jerome Glisse <jglisse@redhat.com>
To: Boris Lukashev <blukashev@sempervictus.com>
Cc: Igor Stoppa <igor.stoppa@huawei.com>,
Jann Horn <jannh@google.com>, Kees Cook <keescook@chromium.org>,
Michal Hocko <mhocko@kernel.org>,
Laura Abbott <labbott@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <willy@infradead.org>,
Christoph Lameter <cl@linux.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>,
kernel list <linux-kernel@vger.kernel.org>,
Kernel Hardening <kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] [PATCH 4/6] Protectable Memory
Date: Thu, 25 Jan 2018 10:38:39 -0500 [thread overview]
Message-ID: <20180125153839.GA3542@redhat.com> (raw)
In-Reply-To: <CAFUG7CfP_UyEH=1dmX=wsBz73+fQ0syDAy8ArKT0d4nMyf9n-g@mail.gmail.com>
On Thu, Jan 25, 2018 at 10:14:28AM -0500, Boris Lukashev wrote:
> On Thu, Jan 25, 2018 at 6:59 AM, Igor Stoppa <igor.stoppa@huawei.com> 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,
Jerome
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-01-25 15:38 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-24 17:56 [RFC PATCH v11 0/6] mm: security: ro protection for dynamic data Igor Stoppa
2018-01-24 17:56 ` [PATCH 1/6] genalloc: track beginning of allocations Igor Stoppa
2018-01-24 17:56 ` [PATCH 2/6] genalloc: selftest Igor Stoppa
2018-01-24 17:56 ` [PATCH 3/6] struct page: add field for vm_struct Igor Stoppa
2018-01-24 17:56 ` [PATCH 4/6] Protectable Memory Igor Stoppa
2018-01-24 19:10 ` [kernel-hardening] " Jann Horn
2018-01-25 11:59 ` Igor Stoppa
2018-01-25 15:14 ` Boris Lukashev
2018-01-25 15:38 ` Jerome Glisse [this message]
2018-01-26 12:28 ` Igor Stoppa
2018-01-26 16:36 ` Boris Lukashev
2018-01-30 13:46 ` Igor Stoppa
2018-01-26 5:35 ` Matthew Wilcox
2018-01-26 11:46 ` Igor Stoppa
2018-02-02 18:39 ` Christopher Lameter
2018-02-03 15:38 ` Igor Stoppa
2018-02-03 19:57 ` Igor Stoppa
2018-02-03 20:12 ` Boris Lukashev
2018-02-03 20:32 ` Igor Stoppa
2018-02-03 22:29 ` Boris Lukashev
2018-02-04 15:05 ` Igor Stoppa
2018-02-12 23:27 ` Kees Cook
2018-02-13 0:40 ` Laura Abbott
2018-02-13 1:25 ` Kees Cook
2018-02-13 3:39 ` Jann Horn
2018-02-13 16:09 ` Laura Abbott
2018-02-13 21:43 ` Kees Cook
2018-02-14 19:06 ` arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) Laura Abbott
2018-02-14 19:28 ` Ard Biesheuvel
2018-02-14 20:13 ` Laura Abbott
2018-02-14 19:29 ` Kees Cook
2018-02-14 19:35 ` Kees Cook
2018-02-20 16:28 ` Igor Stoppa
2018-02-21 22:22 ` Kees Cook
2018-02-14 19:48 ` Kees Cook
2018-02-14 22:13 ` Tycho Andersen
2018-02-14 22:27 ` Kees Cook
2018-02-13 15:20 ` [kernel-hardening] [PATCH 4/6] Protectable Memory Igor Stoppa
2018-02-13 15:20 ` Igor Stoppa
[not found] ` <5a83024c.64369d0a.a1e94.cdd6SMTPIN_ADDED_BROKEN@mx.google.com>
2018-02-13 18:10 ` [kernel-hardening] " Laura Abbott
2018-02-20 17:16 ` Igor Stoppa
2018-02-21 22:37 ` Kees Cook
2018-02-05 15:40 ` Christopher Lameter
2018-02-09 11:17 ` Igor Stoppa
2018-01-26 19:41 ` Igor Stoppa
2018-01-24 17:56 ` [PATCH 5/6] Documentation for Pmalloc Igor Stoppa
2018-01-24 19:14 ` Ralph Campbell
2018-01-25 7:53 ` Igor Stoppa
2018-01-24 17:56 ` [PATCH 6/6] Pmalloc: self-test Igor Stoppa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180125153839.GA3542@redhat.com \
--to=jglisse@redhat.com \
--cc=blukashev@sempervictus.com \
--cc=cl@linux.com \
--cc=hch@infradead.org \
--cc=igor.stoppa@huawei.com \
--cc=jannh@google.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).