Re: Hyplets - User Space Interrupts

On Fri, 08 Jun 2018 13:55:02 +0100,
raz wrote:
> 
> We would like to present ARM hyplets. Hyplets are an innovative way
> to code interrupt service routines under ARM.  Hyplets provide high
> performance, security, running time predictability ,an RPC mechanism
> and a possible solution for the priority inversion problem. Hyplets
> uses special features of ARM hypervisor memory architecture.  We
> demonstrate Hyplets implementation in the C programming language on
> ARMv8 platform and under the Linux kernel.  We provide performance
> measurements, use cases and security scenarios.
> 
> Hyplets are based on the concept of a delicate separation within a
> running process. Instead of running multiple operating systems
> kernels in order to segment and divide the system resources, the
> hyplet divides the Linux process into two execution modes. One part
> of the process would execute in an isolated, non-interrupted
> privileged safe execution environment while other parts of the
> process would execute in a regular user mode. However, both
> execution modes run in the same Application processors.

I haven't had a chance to look at the code (the provided URL just
gives me a 502), but mentioning userspace-controlled code at EL2 and
security in the same sentence sounds a bit... odd.


> The trivial approach of migrating code to kernel space to improve
> performance requires a high level of kernel programming skills.
> Alternatively, if we try to access a user space code from the ISR,
> it would probably require a context switch because there is no
> guarantee that the current process in the processor is the one with
> hyplet code. We needed to make sure that the hyplet code is always
> accessible and this could be achieved only by disabling evacuation
> of the hyplet code and data from the current translation table. So,
> we we chose to use TTBR0_EL2 ( the translation table register) to
> constantly hold the hyplet code.  In order to map user space tasks
> we modified the Linux ARM-KVM mappings infrastructure to map a user
> space code in tandem with some kernel space data.

So writing kernel code is hard, but writing hypervisor-level is much
easier? I'll try to remember that! ;-)

Again, I couldn't look at your code nor any data, but have you
considered using the KVM API to run code as a guest at EL1 instead? I
know of at least one project doing so to get the kernel out of the way
and get fast timer access.

Thanks,

	M.

-- 
Jazz is not dead, it just smell funny.