Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-06 Thread Kirill A. Shutemov
On Mon, Mar 05, 2018 at 11:07:55AM -0800, Dave Hansen wrote: > On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > > kmap_atomic_keyid() would map the page with the specified KeyID. > > For now it's dummy implementation that would be replaced later. > > I think you need to explain the tradeoffs

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-06 Thread Kirill A. Shutemov
On Mon, Mar 05, 2018 at 11:07:55AM -0800, Dave Hansen wrote: > On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > > kmap_atomic_keyid() would map the page with the specified KeyID. > > For now it's dummy implementation that would be replaced later. > > I think you need to explain the tradeoffs

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-06 Thread Kirill A. Shutemov
On Mon, Mar 05, 2018 at 11:03:55AM -0800, Dave Hansen wrote: > On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > > -#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > > - alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr) > > #define

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-06 Thread Kirill A. Shutemov
On Mon, Mar 05, 2018 at 11:03:55AM -0800, Dave Hansen wrote: > On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > > -#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > > - alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr) > > #define

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-05 Thread Dave Hansen
On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > kmap_atomic_keyid() would map the page with the specified KeyID. > For now it's dummy implementation that would be replaced later. I think you need to explain the tradeoffs here. We could just change the linear map around, but you don't. Why?

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-05 Thread Dave Hansen
On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > kmap_atomic_keyid() would map the page with the specified KeyID. > For now it's dummy implementation that would be replaced later. I think you need to explain the tradeoffs here. We could just change the linear map around, but you don't. Why?

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-05 Thread Dave Hansen
On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > -#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > - alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr) > #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE > +#define __alloc_zeroed_user_highpage(movableflags,

Re: [RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-05 Thread Dave Hansen
On 03/05/2018 08:26 AM, Kirill A. Shutemov wrote: > -#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \ > - alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr) > #define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE > +#define __alloc_zeroed_user_highpage(movableflags,

[RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-05 Thread Kirill A. Shutemov
The hardware/CPU does not enforce coherency between mappings of the same physical page with different KeyIDs or encrypt ion keys. We are responsible for cache management. We have to flush cache on allocation and freeing of encrypted page. Failing to do this may lead to data corruption. Zeroing

[RFC, PATCH 18/22] x86/mm: Handle allocation of encrypted pages

2018-03-05 Thread Kirill A. Shutemov
The hardware/CPU does not enforce coherency between mappings of the same physical page with different KeyIDs or encrypt ion keys. We are responsible for cache management. We have to flush cache on allocation and freeing of encrypted page. Failing to do this may lead to data corruption. Zeroing