On Mon, 2019-06-17 at 18:43 -0700, Andy Lutomirski wrote: > On Mon, Jun 17, 2019 at 6:35 PM Kai Huang <[email protected]> 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); > > > > > > > > > > So I think it really has to be: > > > > > fd = open("/dev/anything987"); > > > > > ioctl(fd, ENCRYPT_ME); > > > > > mmap(fd); > > > > > > > > This requires "/dev/anything987" to support ENCRYPT_ME ioctl, right? > > > > > > > > So to support NVDIMM (DAX), we need to add ENCRYPT_ME ioctl to DAX? > > > > > > Yes and yes, or we do it with layers -- see below. > > > > > > I don't see how we can credibly avoid this. If we try to do MKTME > > > behind the DAX driver's back, aren't we going to end up with cache > > > coherence problems? > > > > I am not sure whether I understand correctly but how is cache coherence > > problem related to > > putting > > MKTME concept to different layers? To make MKTME work with DAX/NVDIMM, I > > think no matter which > > layer > > MKTME concept resides, eventually we need to put keyID into PTE which maps > > to NVDIMM, and kernel > > needs to manage cache coherence for NVDIMM just like for normal memory > > showed in this series? > > > > I mean is that, to avoid cache coherence problems, something has to > prevent user code from mapping the same page with two different key > ids. If the entire MKTME mechanism purely layers on top of DAX, > something needs to prevent the underlying DAX device from being mapped > at the same time as the MKTME-decrypted view. This is obviously > doable, but it's not automatic.
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 ptr1/ptr2 example"? Thanks, -Kai
