Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Michael S. Tsirkin
On Tue, Nov 22, 2016 at 04:41:37PM +0100, Borislav Petkov wrote: > On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote: > > The issue is it's a (potential) security hole, not a slowdown. > > How? Because the bounce buffers will be unencrypted and someone might > intercept them? Or

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Michael S. Tsirkin
On Tue, Nov 22, 2016 at 04:41:37PM +0100, Borislav Petkov wrote: > On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote: > > The issue is it's a (potential) security hole, not a slowdown. > > How? Because the bounce buffers will be unencrypted and someone might > intercept them? Or

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Borislav Petkov
On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote: > The issue is it's a (potential) security hole, not a slowdown. How? Because the bounce buffers will be unencrypted and someone might intercept them? > To disable unsecure things. If someone enables SEV one might have an >

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Borislav Petkov
On Tue, Nov 22, 2016 at 05:22:38PM +0200, Michael S. Tsirkin wrote: > The issue is it's a (potential) security hole, not a slowdown. How? Because the bounce buffers will be unencrypted and someone might intercept them? > To disable unsecure things. If someone enables SEV one might have an >

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Michael S. Tsirkin
On Tue, Nov 22, 2016 at 12:38:59PM +0100, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > > > Makes sense, but I think at least a dmesg warning here > > > might be a good idea. > > > > Good idea. Should it be a warning when it is first being set up or > >

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Michael S. Tsirkin
On Tue, Nov 22, 2016 at 12:38:59PM +0100, Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > > > Makes sense, but I think at least a dmesg warning here > > > might be a good idea. > > > > Good idea. Should it be a warning when it is first being set up or > >

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Borislav Petkov
On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > > Makes sense, but I think at least a dmesg warning here > > might be a good idea. > > Good idea. Should it be a warning when it is first being set up or > a warning the first time the bounce buffers need to be used. Or maybe >

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-22 Thread Borislav Petkov
On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > > Makes sense, but I think at least a dmesg warning here > > might be a good idea. > > Good idea. Should it be a warning when it is first being set up or > a warning the first time the bounce buffers need to be used. Or maybe >

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Tom Lendacky
On 11/15/2016 12:17 PM, Radim Krčmář wrote: > 2016-11-15 11:02-0600, Tom Lendacky: >> On 11/15/2016 8:39 AM, Radim Krčmář wrote: >>> 2016-11-09 18:37-0600, Tom Lendacky: Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Tom Lendacky
On 11/15/2016 12:17 PM, Radim Krčmář wrote: > 2016-11-15 11:02-0600, Tom Lendacky: >> On 11/15/2016 8:39 AM, Radim Krčmář wrote: >>> 2016-11-09 18:37-0600, Tom Lendacky: Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Michael S. Tsirkin
On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: > >> Since DMA addresses will effectively look like 48-bit addresses when the > >> memory encryption mask is set,

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Michael S. Tsirkin
On Tue, Nov 15, 2016 at 12:29:35PM -0600, Tom Lendacky wrote: > On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: > >> Since DMA addresses will effectively look like 48-bit addresses when the > >> memory encryption mask is set,

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Tom Lendacky
On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Tom Lendacky
On 11/15/2016 9:16 AM, Michael S. Tsirkin wrote: > On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Radim Krčmář
2016-11-15 11:02-0600, Tom Lendacky: > On 11/15/2016 8:39 AM, Radim Krčmář wrote: >> 2016-11-09 18:37-0600, Tom Lendacky: >>> Since DMA addresses will effectively look like 48-bit addresses when the >>> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >>> device performing

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Radim Krčmář
2016-11-15 11:02-0600, Tom Lendacky: > On 11/15/2016 8:39 AM, Radim Krčmář wrote: >> 2016-11-09 18:37-0600, Tom Lendacky: >>> Since DMA addresses will effectively look like 48-bit addresses when the >>> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >>> device performing

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Tom Lendacky
On 11/15/2016 8:39 AM, Radim Krčmář wrote: > 2016-11-09 18:37-0600, Tom Lendacky: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Tom Lendacky
On 11/15/2016 8:39 AM, Radim Krčmář wrote: > 2016-11-09 18:37-0600, Tom Lendacky: >> Since DMA addresses will effectively look like 48-bit addresses when the >> memory encryption mask is set, SWIOTLB is needed if the DMA mask of the >> device performing the DMA does not support 48-bits. SWIOTLB

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Michael S. Tsirkin
On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Michael S. Tsirkin
On Wed, Nov 09, 2016 at 06:37:23PM -0600, Tom Lendacky wrote: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Radim Krčmář
2016-11-09 18:37-0600, Tom Lendacky: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to create un-encrypted

Re: [RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-15 Thread Radim Krčmář
2016-11-09 18:37-0600, Tom Lendacky: > Since DMA addresses will effectively look like 48-bit addresses when the > memory encryption mask is set, SWIOTLB is needed if the DMA mask of the > device performing the DMA does not support 48-bits. SWIOTLB will be > initialized to create un-encrypted

[RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-09 Thread Tom Lendacky
Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create un-encrypted bounce buffers for use by these devices.

[RFC PATCH v3 13/20] x86: DMA support for memory encryption

2016-11-09 Thread Tom Lendacky
Since DMA addresses will effectively look like 48-bit addresses when the memory encryption mask is set, SWIOTLB is needed if the DMA mask of the device performing the DMA does not support 48-bits. SWIOTLB will be initialized to create un-encrypted bounce buffers for use by these devices.