From: Tom Roeder <tmroeder@google.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Sagi Grimberg <sagi@grimberg.me>,
linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org,
Marios Pomonis <pomonis@google.com>, Jens Axboe <axboe@fb.com>,
Peter Gonda <pgonda@google.com>, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH] nvme: Cache DMA descriptors to prevent corruption.
Date: Thu, 19 Nov 2020 17:09:40 -0800 [thread overview]
Message-ID: <20201120010940.GA2943603@google.com> (raw)
In-Reply-To: <20201119210914.GB2855047@dhcp-10-100-145-180.wdc.com>
On Thu, Nov 19, 2020 at 01:09:14PM -0800, Keith Busch wrote:
>On Thu, Nov 19, 2020 at 10:59:19AM -0800, Tom Roeder wrote:
>> This patch changes the NVMe PCI implementation to cache host_mem_descs
>> in non-DMA memory instead of depending on descriptors stored in DMA
>> memory. This change is needed under the malicious-hypervisor threat
>> model assumed by the AMD SEV and Intel TDX architectures, which encrypt
>> guest memory to make it unreadable. Some versions of these architectures
>> also make it cryptographically hard to modify guest memory without
>> detection.
>>
>> On these architectures, Linux generally leaves DMA memory unencrypted so
>> that devices can still communicate directly with the kernel: DMA memory
>> remains readable to and modifiable by devices. This means that this
>> memory is also accessible to a hypervisor.
>>
>> However, this means that a malicious hypervisor could modify the addr or
>> size fields of descriptors and cause the NVMe driver to call
>> dma_free_attrs on arbitrary addresses or on the right addresses but with
>> the wrong size. To prevent this attack, this commit changes the code to
>> cache those descriptors in non-DMA memory and to use the cached values
>> when freeing the memory they describe.
>
>If the hypervisor does that, then the device may use the wrong
>addresses, too. I guess you can't do anything about that from the
>driver, though.
I agree; I don't think there's anything the driver can do about that.
>
>> + /* Cache the host_mem_descs in non-DMA memory so a malicious hypervisor
>> + * can't change them.
>> + */
>> + struct nvme_host_mem_buf_desc *host_mem_descs_cache;
>> void **host_mem_desc_bufs;
>
>This is never seen by an nvme device, so no need for an nvme specific
>type here. You can use arch native types.
Thanks! I'll change the type to a new struct that has the addr and size
fields as native integers and send out a v2 for this patch that makes
that change and cleans up a couple of minor style issues in my code.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
WARNING: multiple messages have this Message-ID (diff)
From: Tom Roeder <tmroeder@google.com>
To: Keith Busch <kbusch@kernel.org>
Cc: Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>, Peter Gonda <pgonda@google.com>,
Marios Pomonis <pomonis@google.com>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: Cache DMA descriptors to prevent corruption.
Date: Thu, 19 Nov 2020 17:09:40 -0800 [thread overview]
Message-ID: <20201120010940.GA2943603@google.com> (raw)
In-Reply-To: <20201119210914.GB2855047@dhcp-10-100-145-180.wdc.com>
On Thu, Nov 19, 2020 at 01:09:14PM -0800, Keith Busch wrote:
>On Thu, Nov 19, 2020 at 10:59:19AM -0800, Tom Roeder wrote:
>> This patch changes the NVMe PCI implementation to cache host_mem_descs
>> in non-DMA memory instead of depending on descriptors stored in DMA
>> memory. This change is needed under the malicious-hypervisor threat
>> model assumed by the AMD SEV and Intel TDX architectures, which encrypt
>> guest memory to make it unreadable. Some versions of these architectures
>> also make it cryptographically hard to modify guest memory without
>> detection.
>>
>> On these architectures, Linux generally leaves DMA memory unencrypted so
>> that devices can still communicate directly with the kernel: DMA memory
>> remains readable to and modifiable by devices. This means that this
>> memory is also accessible to a hypervisor.
>>
>> However, this means that a malicious hypervisor could modify the addr or
>> size fields of descriptors and cause the NVMe driver to call
>> dma_free_attrs on arbitrary addresses or on the right addresses but with
>> the wrong size. To prevent this attack, this commit changes the code to
>> cache those descriptors in non-DMA memory and to use the cached values
>> when freeing the memory they describe.
>
>If the hypervisor does that, then the device may use the wrong
>addresses, too. I guess you can't do anything about that from the
>driver, though.
I agree; I don't think there's anything the driver can do about that.
>
>> + /* Cache the host_mem_descs in non-DMA memory so a malicious hypervisor
>> + * can't change them.
>> + */
>> + struct nvme_host_mem_buf_desc *host_mem_descs_cache;
>> void **host_mem_desc_bufs;
>
>This is never seen by an nvme device, so no need for an nvme specific
>type here. You can use arch native types.
Thanks! I'll change the type to a new struct that has the addr and size
fields as native integers and send out a v2 for this patch that makes
that change and cleans up a couple of minor style issues in my code.
next prev parent reply other threads:[~2020-11-20 1:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-19 18:59 [PATCH] nvme: Cache DMA descriptors to prevent corruption Tom Roeder
2020-11-19 18:59 ` Tom Roeder
2020-11-19 21:09 ` Keith Busch
2020-11-19 21:09 ` Keith Busch
2020-11-20 1:09 ` Tom Roeder [this message]
2020-11-20 1:09 ` Tom Roeder
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=20201120010940.GA2943603@google.com \
--to=tmroeder@google.com \
--cc=axboe@fb.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=pgonda@google.com \
--cc=pomonis@google.com \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.