On Thu, Jun 15, 2017 at 08:54:57AM -0700, Jethro Beekman wrote:
On 2017-03-23 11:14, Jarkko Sakkinen wrote:
> On Thu, Mar 23, 2017 at 10:16:00AM -0700, Jethro Beekman wrote:
> > As long as we don't inadvertently create user ABI that needs to be changed
I
> > think that's fine. I think before anything will be accepted upstream we
need
> > to at least figure out the mmap story as described in my second email
> > yesterday.
>
> Great, I'll try to find time to study them through. I'm soon done
> with the LE. After I've finished that and before doing accompanying
> kernel changes I'll check this through.
I don't know what your envisioned timeline for upstreaming is, but I think
it's important that we upstream an interface that's going to be forward
I was planning to send patches already for 4.13 but got bumped in the
problems with my signing tool that have been since fixed [1].
The LE is working together with a host program and has zero SDK
dependecies. I'm now working on the kernel changes and try to target
them to 4.14.
[1] Probably would make sense to validate the permission bits in secinfo
when TCS page is supplied and return -EINVAL if any of the RWX bits are
set. The CPU will silently just reset them. This caused the mismatch in
the hash and is not trivial to deduce if you don't know already that the
hardware behaves this way.
compatible with our plans for debugging. We don't need to
implement anything
right now, but I do want to make sure the user interface we settle on isn't
forever inconvenient. As stated, in particular the points mention in my
email dated 2017-03-22 11:35 PDT should be considered.
Jethro Beekman | Fortanix
It is your job to check the patches once I send them that they are not
incompatible with your requirements and report if they are. It is my
job to fix the issues to make them align with your requirements.
/Jarkko