On 6/18/19 9:36 AM, Andy Lutomirski wrote:
> Should MKTME+DAX encrypt the entire volume or should it encrypt individual
> files? Or both?
Our current thought is that there should be two modes: One for entire
DAX namespaces and one for filesystem DAX that would allow it to be at
the file level.
> On Jun 18, 2019, at 9:22 AM, Dave Hansen wrote:
>
> On 6/18/19 9:15 AM, Kirill A. Shutemov wrote:
>>> We'd need two rules:
>>> 1. A page must not be faulted into a VMA if the page's page_keyid()
>>> is not consistent with the VMA's
>>> 2. Upon changing the VMA's KeyID, all underlying PTEs
On 6/18/19 9:15 AM, Kirill A. Shutemov wrote:
>> We'd need two rules:
>> 1. A page must not be faulted into a VMA if the page's page_keyid()
>>is not consistent with the VMA's
>> 2. Upon changing the VMA's KeyID, all underlying PTEs must either be
>>checked or zapped.
>>
>> If the rules
On Tue, Jun 18, 2019 at 07:09:36AM -0700, Dave Hansen wrote:
> On 6/18/19 2:12 AM, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 02:23:31PM +1200, Kai Huang wrote:
> >> Assuming I am understanding the context correctly, yes from this
> >> perspective it seems having
> >> sys_encrypt is
On 6/17/19 6:50 PM, Andy Lutomirski wrote:
> I'm also wondering whether the kernel will always be able to be a
> one-stop shop for key allocation -- if the MKTME hardware gains
> interesting new uses down the road, who knows how key allocation will
> work?
I can't share all the details on LKML,
On 6/17/19 5:15 PM, Andy Lutomirski wrote:
>>> But I really expect that the encryption of a DAX device will actually
>>> be a block device setting and won't look like this at all. It'll be
>>> more like dm-crypt except without device mapper.
>> Are you suggesting not to support MKTME for DAX, or
On 6/18/19 2:12 AM, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 02:23:31PM +1200, Kai Huang wrote:
>> Assuming I am understanding the context correctly, yes from this perspective
>> it seems having
>> sys_encrypt is annoying, and having ENCRYPT_ME should be better. But Dave
>> said "nobody
On Tue, Jun 18, 2019 at 02:23:31PM +1200, Kai Huang wrote:
> Assuming I am understanding the context correctly, yes from this perspective
> it seems having
> sys_encrypt is annoying, and having ENCRYPT_ME should be better. But Dave
> said "nobody is going to
> do what you suggest in the
On Mon, Jun 17, 2019 at 7:11 PM Kai Huang wrote:
>
> On Mon, 2019-06-17 at 18:50 -0700, Andy Lutomirski wrote:
> > On Mon, Jun 17, 2019 at 5:48 PM Kai Huang wrote:
> > >
> > >
> > > >
> > > > > And another silly argument: if we had /dev/mktme, then we could
> > > > > possibly get away with
On Mon, Jun 17, 2019 at 6:40 PM Andy Lutomirski wrote:
>
> On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas
> wrote:
> >
> > On 6/17/19 6:59 PM, Kai Huang wrote:
> > > On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>
> > >
> > > And yes from my reading (better to have AMD guys to confirm)
On Mon, 2019-06-17 at 18:43 -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 6:35 PM Kai Huang wrote:
> >
> >
> > > > >
> > > > > I'm having a hard time imagining that ever working -- wouldn't it blow
> > > > > up if someone did:
> > > > >
> > > > > fd = open("/dev/anything987");
> > >
On Mon, 2019-06-17 at 18:50 -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 5:48 PM Kai Huang wrote:
> >
> >
> > >
> > > > And another silly argument: if we had /dev/mktme, then we could
> > > > possibly get away with avoiding all the keyring stuff entirely.
> > > > Instead, you open
On 6/17/19 8:40 PM, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas
> wrote:
>>
>> On 6/17/19 6:59 PM, Kai Huang wrote:
>>> On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>
>>>
>>> And yes from my reading (better to have AMD guys to confirm) SEV guest uses
>>>
On Mon, Jun 17, 2019 at 5:48 PM Kai Huang wrote:
>
>
> >
> > > And another silly argument: if we had /dev/mktme, then we could
> > > possibly get away with avoiding all the keyring stuff entirely.
> > > Instead, you open /dev/mktme and you get your own key under the hook.
> > > If you want two
On Mon, Jun 17, 2019 at 6:35 PM Kai Huang wrote:
>
>
> > > >
> > > > I'm having a hard time imagining that ever working -- wouldn't it blow
> > > > up if someone did:
> > > >
> > > > fd = open("/dev/anything987");
> > > > ptr1 = mmap(fd);
> > > > ptr2 = mmap(fd);
> > > > sys_encrypt(ptr1);
> > >
On Mon, Jun 17, 2019 at 6:34 PM Lendacky, Thomas
wrote:
>
> On 6/17/19 6:59 PM, Kai Huang wrote:
> > On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
> >
> > And yes from my reading (better to have AMD guys to confirm) SEV guest uses
> > anonymous memory, but it
> > also pins all guest
> > >
> > > I'm having a hard time imagining that ever working -- wouldn't it blow
> > > up if someone did:
> > >
> > > fd = open("/dev/anything987");
> > > ptr1 = mmap(fd);
> > > ptr2 = mmap(fd);
> > > sys_encrypt(ptr1);
> > >
> > > So I think it really has to be:
> > > fd =
On 6/17/19 6:59 PM, Kai Huang wrote:
> On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
>> Tom Lendacky, could you take a look down in the message to the talk of
>> SEV? I want to make sure I'm not misrepresenting what it does today.
Sorry, I'm traveling this week, so responses will be
>
> > And another silly argument: if we had /dev/mktme, then we could
> > possibly get away with avoiding all the keyring stuff entirely.
> > Instead, you open /dev/mktme and you get your own key under the hook.
> > If you want two keys, you open /dev/mktme twice. If you want some
> > other
On Mon, Jun 17, 2019 at 5:05 PM Kai Huang wrote:
>
> On Mon, 2019-06-17 at 12:12 -0700, Andy Lutomirski wrote:
> > On Mon, Jun 17, 2019 at 11:37 AM Dave Hansen wrote:
> > >
> > > Tom Lendacky, could you take a look down in the message to the talk of
> > > SEV? I want to make sure I'm not
On Mon, 2019-06-17 at 12:12 -0700, Andy Lutomirski wrote:
> On Mon, Jun 17, 2019 at 11:37 AM Dave Hansen wrote:
> >
> > Tom Lendacky, could you take a look down in the message to the talk of
> > SEV? I want to make sure I'm not misrepresenting what it does today.
> > ...
> >
> >
> > > > I
On Mon, 2019-06-17 at 11:27 -0700, Dave Hansen wrote:
> Tom Lendacky, could you take a look down in the message to the talk of
> SEV? I want to make sure I'm not misrepresenting what it does today.
> ...
>
>
> > > I actually don't care all that much which one we end up with. It's not
> > >
>> Where if we have something like mprotect() (or madvise() or something
>> else taking pointer), we can just do:
>>
>> fd = open("/dev/anything987");
>> ptr = mmap(fd);
>> sys_encrypt(ptr);
>
> I'm having a hard time imagining that ever working -- wouldn't it blow
> up if
On Mon, Jun 17, 2019 at 11:37 AM Dave Hansen wrote:
>
> Tom Lendacky, could you take a look down in the message to the talk of
> SEV? I want to make sure I'm not misrepresenting what it does today.
> ...
>
>
> >> I actually don't care all that much which one we end up with. It's not
> >> like
Tom Lendacky, could you take a look down in the message to the talk of
SEV? I want to make sure I'm not misrepresenting what it does today.
...
>> I actually don't care all that much which one we end up with. It's not
>> like the extra syscall in the second options means much.
>
> The benefit
On Mon, Jun 17, 2019 at 8:28 AM Dave Hansen wrote:
>
> On 6/17/19 8:07 AM, Andy Lutomirski wrote:
> > I still find it bizarre that this is conflated with mprotect().
>
> This needs to be in the changelog. But, for better or worse, it's
> following the mprotect_pkey() pattern.
>
> Other than the
On 6/17/19 8:07 AM, Andy Lutomirski wrote:
> I still find it bizarre that this is conflated with mprotect().
This needs to be in the changelog. But, for better or worse, it's
following the mprotect_pkey() pattern.
Other than the obvious "set the key on this memory", we're looking for
two other
On Wed, May 8, 2019 at 7:44 AM Kirill A. Shutemov
wrote:
>
> From: Alison Schofield
>
> Implement memory encryption for MKTME (Multi-Key Total Memory
> Encryption) with a new system call that is an extension of the
> legacy mprotect() system call.
>
> In encrypt_mprotect the caller must pass a
On Fri, Jun 14, 2019 at 05:32:31PM -0700, Alison Schofield wrote:
> On Fri, Jun 14, 2019 at 01:51:37PM +0200, Peter Zijlstra wrote:
> > On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote:
> snip
> > > /*
> > > - * When pkey==NO_KEY we get legacy mprotect behavior here.
> > > + *
On Fri, Jun 14, 2019 at 01:51:37PM +0200, Peter Zijlstra wrote:
> On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote:
snip
> > /*
> > - * When pkey==NO_KEY we get legacy mprotect behavior here.
> > + * do_mprotect_ext() supports the legacy mprotect behavior plus extensions
> > + *
On Fri, Jun 14, 2019 at 01:47:32PM +0200, Peter Zijlstra wrote:
> On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote:
> > diff --git a/fs/exec.c b/fs/exec.c
> > index 2e0033348d8e..695c121b34b3 100644
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -755,8 +755,8 @@ int
On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote:
> @@ -347,7 +348,8 @@ static int prot_none_walk(struct vm_area_struct *vma,
> unsigned long start,
>
> int
> mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev,
> - unsigned long start, unsigned
On Wed, May 08, 2019 at 05:44:05PM +0300, Kirill A. Shutemov wrote:
> diff --git a/fs/exec.c b/fs/exec.c
> index 2e0033348d8e..695c121b34b3 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -755,8 +755,8 @@ int setup_arg_pages(struct linux_binprm *bprm,
> vm_flags |= mm->def_flags;
>
From: Alison Schofield
Implement memory encryption for MKTME (Multi-Key Total Memory
Encryption) with a new system call that is an extension of the
legacy mprotect() system call.
In encrypt_mprotect the caller must pass a handle to a previously
allocated and programmed MKTME encryption key. The
34 matches
Mail list logo
