Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-15 Thread Stefano Stabellini 
On Mon, 15 May 2017, George Dunlap wrote:
> [Reducing CC list now that we're off the topic of modules]
> 
> On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk
>  wrote:
> > Stefano,
> >
> > On 12 May 2017 at 21:43, Stefano Stabellini  wrote:
> >
> >> On the topic of the technical reasons for being out of the hypervisor
> >> (EL0 app or stubdom), I'll spend a couple of words on security.
> >>
> >> How large are these components? If they increase the hypervisor code
> >> size too much, it's best if they are run elsewhere.
> > I'm talking about OP-TEE now.
> > "Large" as "large code base"? I have shared my PoC driver. Here it is
> > [1]. My expectation: 1,000-2,000 lines of code for mediator + some
> > OP-TEE headers.
> >
> >> What is their guest-exposed attack surface? If it's large it's best to
> >> run them out of the hypervisor.
> > OP-TEE mediator will trap SMC calls and parse parameter buffers
> > according to OP-TEE ABI specification. ABI is very simple, so I can't
> > say that there will be attack surface.
> >
> >> My gut feeling is that both these points might be a problem.
> > The real problem, that is needs the same privileges, as hypervisor
> > itself. I wrote this in parallel thread:
> > it needs to pin guest pages (to ensure that page will be not
> > transferred to another domain, while OP-TEE uses it), it needs to map
> > guest page so it can do IPA->PA translation in a command buffer, it
> > needs to execute SMCs (but we can limit it there, thanks to SMCCC),
> > probably it will need to inject vIRQ to guest to wake it up.
> 
> Xen is different than Linux in that it attempts to take a "practical
> microkernel" approach.  "Microkernel" meaning that we prefer to do as
> much *outside* of the hypervisor as possible.  "Practical" meaning, if
> running it outside the hypervisor causes too much complexity or too
> much performance overhead, then we don't stand on ideology but allow
> things to run inside of Xen.
> 
> With the exception of SMCs (which I don't know anything about), device
> models (e.g., QEMU) already have  of this functionality on x86,
> running from dom0 or from a stubdomain.
> 
> Do OP-TEE mediators require a lot of performance?  I.e., do the
> operations happen very frequently and/or are they particularly
> latency-sensitive?  If not then it might be worth implementing it as a
> dom0 device model first, and then exploring higher-performing options
> if that turns out to be too slow.

The whole discussion started from the need for something that has lower
latency, and more importantly, more deterministic latency, than a dom0
device model.

Any use-cases with even the weakest of real-time requirements won't be
satisfied by a dom0 device model, where the max latency is basically
infinite.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-15 Thread George Dunlap 
[Reducing CC list now that we're off the topic of modules]

On Fri, May 12, 2017 at 8:04 PM, Volodymyr Babchuk
 wrote:
> Stefano,
>
> On 12 May 2017 at 21:43, Stefano Stabellini  wrote:
>
>> On the topic of the technical reasons for being out of the hypervisor
>> (EL0 app or stubdom), I'll spend a couple of words on security.
>>
>> How large are these components? If they increase the hypervisor code
>> size too much, it's best if they are run elsewhere.
> I'm talking about OP-TEE now.
> "Large" as "large code base"? I have shared my PoC driver. Here it is
> [1]. My expectation: 1,000-2,000 lines of code for mediator + some
> OP-TEE headers.
>
>> What is their guest-exposed attack surface? If it's large it's best to
>> run them out of the hypervisor.
> OP-TEE mediator will trap SMC calls and parse parameter buffers
> according to OP-TEE ABI specification. ABI is very simple, so I can't
> say that there will be attack surface.
>
>> My gut feeling is that both these points might be a problem.
> The real problem, that is needs the same privileges, as hypervisor
> itself. I wrote this in parallel thread:
> it needs to pin guest pages (to ensure that page will be not
> transferred to another domain, while OP-TEE uses it), it needs to map
> guest page so it can do IPA->PA translation in a command buffer, it
> needs to execute SMCs (but we can limit it there, thanks to SMCCC),
> probably it will need to inject vIRQ to guest to wake it up.

Xen is different than Linux in that it attempts to take a "practical
microkernel" approach.  "Microkernel" meaning that we prefer to do as
much *outside* of the hypervisor as possible.  "Practical" meaning, if
running it outside the hypervisor causes too much complexity or too
much performance overhead, then we don't stand on ideology but allow
things to run inside of Xen.

With the exception of SMCs (which I don't know anything about), device
models (e.g., QEMU) already have  of this functionality on x86,
running from dom0 or from a stubdomain.

Do OP-TEE mediators require a lot of performance?  I.e., do the
operations happen very frequently and/or are they particularly
latency-sensitive?  If not then it might be worth implementing it as a
dom0 device model first, and then exploring higher-performing options
if that turns out to be too slow.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-12 Thread Volodymyr Babchuk 
Stefano,

On 12 May 2017 at 21:43, Stefano Stabellini  wrote:

> On the topic of the technical reasons for being out of the hypervisor
> (EL0 app or stubdom), I'll spend a couple of words on security.
>
> How large are these components? If they increase the hypervisor code
> size too much, it's best if they are run elsewhere.
I'm talking about OP-TEE now.
"Large" as "large code base"? I have shared my PoC driver. Here it is
[1]. My expectation: 1,000-2,000 lines of code for mediator + some
OP-TEE headers.

> What is their guest-exposed attack surface? If it's large it's best to
> run them out of the hypervisor.
OP-TEE mediator will trap SMC calls and parse parameter buffers
according to OP-TEE ABI specification. ABI is very simple, so I can't
say that there will be attack surface.

> My gut feeling is that both these points might be a problem.
The real problem, that is needs the same privileges, as hypervisor
itself. I wrote this in parallel thread:
it needs to pin guest pages (to ensure that page will be not
transferred to another domain, while OP-TEE uses it), it needs to map
guest page so it can do IPA->PA translation in a command buffer, it
needs to execute SMCs (but we can limit it there, thanks to SMCCC),
probably it will need to inject vIRQ to guest to wake it up.

[1] https://github.com/lorc/xen/tree/staging-4.7/xen/arch/arm/optee
-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-12 Thread Stefano Stabellini 
On Fri, 12 May 2017, George Dunlap wrote:
> So given your examples, I see no reason not to have several
> implementations of different mediators or emulated devices in tree, or
> in a XenProject-managed git repo (like mini-os.git).  I don't know the
> particulars about mediators or the devices you have in mind, but if
> you can show technical reasons why they need to be run in the
> hypervisor rather than somewhere else (for performance or security
> sake, for instance), there's no reason in principle not to add them to
> the hypervisor code; and if they're in the hypervisor, then they
> should be in xen.git.

On the topic of the technical reasons for being out of the hypervisor
(EL0 app or stubdom), I'll spend a couple of words on security.

How large are these components? If they increase the hypervisor code
size too much, it's best if they are run elsewhere.

What is their guest-exposed attack surface? If it's large it's best to
run them out of the hypervisor.

My gut feeling is that both these points might be a problem.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-12 Thread George Dunlap 
[reordering slightly to make the response easier]

On Thu, May 11, 2017 at 7:13 PM, Volodymyr Babchuk
 wrote:
>> Maybe I'm just not familiar with things, but it's hard for me to imagine
>> why you'd need proprietary blobs to disable cpus or scale frequency.
>> Are these really such complex activities that it's worth investing
>> thousands of hours of developer work into developing proprietary
>> solutions that you license?
> Okay, I don't know no platform where you need proprietary blob to
> scale frequency. And I hope, I never will encounter one.
> But I can imagine it: some firmware binary that needs to be uploaded
> into PMIC. Can we store this firmware in the hypervisor? I don't know.
> I'm not a lawyer.

On x86, we do microcode updates, which are (as I understand it) binary
blobs that get passed through the hypervisor to the cpus.  This blob
isn't executed by Xen, so it doesn't seem like you would be able to
argue that passing a binary blob through the hypervisor creates a
derivative / combined work.  In that case the blobs are stored as
files on disk and passed to Xen at boot time (via grub), not compiled
into the Xen binary.  Whether compiling such things into the binary
constitutes a "derived work" is something you'd probably better ask a
lawyer. :-)

If configuring the bootloader to pass extra files to Xen isn't
suitable on ARM for some reason we can probably come up with some
other way of packaging things together which honors the GPL suitably.

 ...some [things can't be included in hypervisor] because of code
 size or complexity.
>>
>> Sorry, just to be clear: below you mentioned modules as a solution, and
>> given the context this would be included.  So can you expand on what you
>> mean that there are things that 1) can't be included in the hypervisor
>> because of code size or complexity, but for which 2) loadable modules
>> would be a suitable solution?
> Well... Device drives? Emulators? For example, if I will write bunch
> of good and neat GPL drivers for some SoC and I'll promise to maintain
> them, will you include them into upstream?
> Or I will write emulator for some arcane device, will it be merged
> into upstream?
> Real case: I will write OP-TEE mediator for one client and Google
> Trusty mediator for other client. Every will have, say, 2,000 lines of
> code. Are there changes, that they both will be merged into
> hypervisor?

[snip]

> Anyways, I have taken your point. No proprietary code in modules. What
> about other parts of discussion? Are you against loadable modules in
> any fashion? What about native apps?

There are several different questions we're getting slightly mixed up here:
1. Should some bit of functionality (like a TEE mediator or device
emulation) live in the xen.git tree?
2. Should that functionality run in the hypervisor address space?
3. Should that functionality be loaded via a loadable module?
4. What place to proprietary components have in a Xen system?

Let me address #4 first.  There are lots of examples of proprietary
*components* of Xen systems.  XenClient used to have a proprietary
device model (a process running in dom0) for helping virtualize
graphics cards; a number of companies have proprietary drivers for
memory sharing or VM introspection.  But all of those are outside of
the Xen address space, interacting with Xen via hypercalls.  As long
as "native apps" (I think we probably need a better name here) are
analogous to a devicemodel stubdomain -- in a separate address space
and acting through a well-defined hypercal interface -- I don't have
any objection to having proprietary ones.

Regarding #1-2, let me first say that how specific it is to a
particular platform or use case isn't actually important to any of
these questions.  The considerations are partly technical, and partly
practical -- how much benefit does it give to the project as a whole
vs the cost?

For a long time there were only two functional schedulers in Xen --
the Credit scheduler (now called "credit1" to distinguish it from
"credit2"), and the ARINC653 scheduler, which is a real-time scheduler
targeted at a very specific use case and industry.  As far as I know
there is only one user.  But it was checked into the Xen tree because
it would obviously be useful to them (benefit) and almost no impact on
anyone else (cost); and it ran inside the hypervisor because that's
the only place to run a scheduler.

So given your examples, I see no reason not to have several
implementations of different mediators or emulated devices in tree, or
in a XenProject-managed git repo (like mini-os.git).  I don't know the
particulars about mediators or the devices you have in mind, but if
you can show technical reasons why they need to be run in the
hypervisor rather than somewhere else (for performance or security
sake, for instance), there's no reason in principle not to add them to
the hypervisor code; and if they're in the hypervisor, then they
should be in xen.git.

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread Volodymyr Babchuk 
Stefano,

>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>> hypervisor. Because when it comes to embedded and automotive, there
>> arise some ugly things, that are needed at hypervisor level:
>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>> MSHIELD with deeply proprietary license), device drivers for vcopros,
>> device drivers for cpufreq, and so on.
>> Some of this things can't be included in hypervisor due to legal
>> issues, some - because of code size or complexity. And we can't run
>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>> some cases they are insecure, in some cases they just don't fit at
>> all.
> I can see that stubdoms can be slow if you require very low latencies.
> Scheduler optimizations (giving stubdoms an higher priority) might be
> able to improve on those.
Yeah, when I wrote "slow" I actually meant "have high latency". Thank
you for correction. Yep, they can be improved to a certain limit.

> But they are not insecure. Also, in what cases they don't fit at all?
About security... I had in mind that case, that we discussed on
community call: secure boot. Say, we put OP-TEE mediator into stubdom.
But as it is sensitive thing, we need to a) check it's signature, b)
create this stubdom before dom0 construction. From other points it as
secure as any other domain.

Regarding "don't fit at all": the virtual coprocessors use-case. I
don't see how we can put vGPU driver into a stubdomain.


>> On other hand you consider EL0 apps as ideal host for emulators only.
>
> Yes, EL0 apps are ideal for emulators, but not just emulators, anything
> that runs deterministically after a guest trap or a timer event could be
> a decent fit for an EL0 app. The issue is the interface between EL0 app
> and Xen, but that can be discussed and designed in a way to satisfy all
> parties.
Okay, we need to discuss it, but looks like this definition covers all
our use-cases.

> But we need to start from somewhere. I suggest you write a simple design
> document to explain the use-case for EL0 apps and their interfaces to
> the rest of the system. We can take the discussion from there. We might
> be able to reach a consensus on a design that works for everybody.
>
> We need a concrete proposal to start from though.
Yes, I agree. Now, when we have discussed this in ML, I have better
vision on this topic. I'll try to present some design document in the
next week.

>> I can see your point, because XEN was always viewed as hypervisor for
>> servers.
>>
>> But servers have different requirements in comparison to embedded
>> applications. Traditional servers does not use hardware accelerated
>> video decoders, they don't need to disable cpu's or scale frequencies
>> to preserve energy (okay, they need to, but it is not as pressing, as
>> on battery-powered device), there almost no proprietary code (or even
>> proprietary blobs, argh!).
>> Looks like virtualization on embedded is the next big thing. Linux
>> kernel was able to satisfy both parties. I hope that XEN can do the
>> same.
> I think that this has not much to do with embedded vs server; it's more
> about the need of supporting new, more complex, hardware and firmware
> interfaces.
Yep, this is more precise.

>
>> So, going back to EL0 apps. Honestly, I'd prefer not to use them as
>> extension mechanism. Yes, they provide isolation, but interfacing with
>> them will be painful. Probably we can leave them to emulators only
>> (but as I can see, PL011 emulator is going to be merged right into
>> hypervisor. Will be there need for other emulators?).
>> What I really want to ask: what do you thing about old good modules
>> like ones in linux kernel? There will be no isolation, this is bad.
>> But:
>>  - you can load proprietary modules if you want to
>>  - they are fast
>>  - you can interface with them in a nativest way possible: just call a
>> function
>
> Proprietary modules are a legal minefield. They are best avoided even in
> Linux. Fortunately, both EL0 apps and stubdoms could be proprietary.
> Thus, especially if you have a requirement for running proprietary
> code, it is key to do EL0 apps and/or stubdoms in Xen on ARM.
As you can see, we already discussed this :) Under "proprietary" I
have meant something like "open source, but not compatible with GPL",
and not it-is-so-secret-that-you-need-to-sign-100-NDAs. Anyways, this
is a hard topic and we need to consider it carefully.


-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread Volodymyr Babchuk 
George,

On 11 May 2017 at 20:14, George Dunlap  wrote:
>>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>>> hypervisor. Because when it comes to embedded and automotive, there
>>> arise some ugly things, that are needed at hypervisor level:
>>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>>> MSHIELD with deeply proprietary license),
>
> If you're going to use a deeply proprietary TEE mediator, then you need
> to find yourself a deeply proprietary hypervisor to go along with it --
> either one you pay a license fee for or one you develop yourself.  It
> would almost certainly be cheaper to improve the open-source one than to
> do either of those.
> Or you can try mixing the two and see what happens; but that doesn't
> seem like a very sound legal strategy to me.
Okay, point taken.

>>> ...some [things can't be included in hypervisor] because of code
>>> size or complexity.
>
> Sorry, just to be clear: below you mentioned modules as a solution, and
> given the context this would be included.  So can you expand on what you
> mean that there are things that 1) can't be included in the hypervisor
> because of code size or complexity, but for which 2) loadable modules
> would be a suitable solution?
Well... Device drives? Emulators? For example, if I will write bunch
of good and neat GPL drivers for some SoC and I'll promise to maintain
them, will you include them into upstream?
Or I will write emulator for some arcane device, will it be merged
into upstream?
Real case: I will write OP-TEE mediator for one client and Google
Trusty mediator for other client. Every will have, say, 2,000 lines of
code. Are there changes, that they both will be merged into
hypervisor?

>>> And we can't run
>>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>>> some cases they are insecure, in some cases they just don't fit at
>>> all.
>>> On other hand you consider EL0 apps as ideal host for emulators only.
>>> I can see your point, because XEN was always viewed as hypervisor for
>>> servers.
>>> But servers have different requirements in comparison to embedded
>>> applications. Traditional servers does not use hardware accelerated
>>> video decoders, they don't need to disable cpu's or scale frequencies
>>> to preserve energy (okay, they need to, but it is not as pressing, as
>>> on battery-powered device), there almost no proprietary code (or even
>>> proprietary blobs, argh!).
>>> Looks like virtualization on embedded is the next big thing. Linux
>>> kernel was able to satisfy both parties. I hope that XEN can do the
>>> same.

> For many of these, there are probably technical solutions that we could
> come up with that would allow proprietary content (such as video
> decoders ) that would have suitable performance without needing access
> to the Xen address space.
Yes, we probably can. But any such solution will require some changes
in hypervisor to accommodate it. So, what we are currently doing? We
are discussing such solutions.

> Maybe I'm just not familiar with things, but it's hard for me to imagine
> why you'd need proprietary blobs to disable cpus or scale frequency.
> Are these really such complex activities that it's worth investing
> thousands of hours of developer work into developing proprietary
> solutions that you license?
Okay, I don't know no platform where you need proprietary blob to
scale frequency. And I hope, I never will encounter one.
But I can imagine it: some firmware binary that needs to be uploaded
into PMIC. Can we store this firmware in the hypervisor? I don't know.
I'm not a lawyer.

> Loading proprietary modules into Linux is as illegal as it would be in
> Xen.  Many people obviously do it anyway, but you are really putting
> yourself at a risk of meeting a guy like Patrick McHardy[1], a private
> individual with copyright on the Linux kernel who by some estimates has
> made almost EUR 2m in the last few years suing companies for GPL violations.
Okay, I didn't know that it is illegal to load non-gpl modules into
Linux kernel. Thank you for sharing this knowledge. But now I'm
curios, why there are EXPORT_SYMBOL_GPL() and plain EXPORT_SYMBOL()? I
though it was intended to separate GPL and non-GPL code.
BTW, "non-GPL code" does not mean "closed-source code". It can be
LGPL, MIT, BSD, or Copyleft license. I can imagine proprietary license
which is compatible with BSD, but is incompatible with GPLv2.

Anyways, I have taken your point. No proprietary code in modules. What
about other parts of discussion? Are you against loadable modules in
any fashion? What about native apps?

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread Stefano Stabellini 
On 11/05/17 16:19, Volodymyr Babchuk wrote:
> Hi Stefano,
> 
> On 10 May 2017 at 21:24, Stefano Stabellini  wrote:
> > I just want to point out that the comparision with tasklets is not
> > helpful. Tasklets involve the idle vcpu, which we are trying to step away
> > from because it increases irq latency. Tasklets don't provide any
> > isolation. The context switch model for the idle vcpu and for EL0 apps
> > is different, thus it has a different cost.
> > 
> > I think we shouldn't mention tasklets in this thread any longer.
> Yep, you are right. Let's forget about tasklets and focus on EL0 apps.
> 
> I want summarize political (opposed to technical) part of the discussion.
> 
> We, here at EPAM, viewed EL0 apps primarily as a way to extend
> hypervisor. Because when it comes to embedded and automotive, there
> arise some ugly things, that are needed at hypervisor level:
> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
> MSHIELD with deeply proprietary license), device drivers for vcopros,
> device drivers for cpufreq, and so on.
> Some of this things can't be included in hypervisor due to legal
> issues, some - because of code size or complexity. And we can't run
> them in stubdoms, because stubdoms are slow for certain use-cases, in
> some cases they are insecure, in some cases they just don't fit at
> all.

I can see that stubdoms can be slow if you require very low latencies.
Scheduler optimizations (giving stubdoms an higher priority) might be
able to improve on those.

But they are not insecure. Also, in what cases they don't fit at all?


> On other hand you consider EL0 apps as ideal host for emulators only.

Yes, EL0 apps are ideal for emulators, but not just emulators, anything
that runs deterministically after a guest trap or a timer event could be
a decent fit for an EL0 app. The issue is the interface between EL0 app
and Xen, but that can be discussed and designed in a way to satisfy all
parties.

But we need to start from somewhere. I suggest you write a simple design
document to explain the use-case for EL0 apps and their interfaces to
the rest of the system. We can take the discussion from there. We might
be able to reach a consensus on a design that works for everybody.

We need a concrete proposal to start from though.


> I can see your point, because XEN was always viewed as hypervisor for
> servers.
>
> But servers have different requirements in comparison to embedded
> applications. Traditional servers does not use hardware accelerated
> video decoders, they don't need to disable cpu's or scale frequencies
> to preserve energy (okay, they need to, but it is not as pressing, as
> on battery-powered device), there almost no proprietary code (or even
> proprietary blobs, argh!).
> Looks like virtualization on embedded is the next big thing. Linux
> kernel was able to satisfy both parties. I hope that XEN can do the
> same.

I think that this has not much to do with embedded vs server; it's more
about the need of supporting new, more complex, hardware and firmware
interfaces.


> So, going back to EL0 apps. Honestly, I'd prefer not to use them as
> extension mechanism. Yes, they provide isolation, but interfacing with
> them will be painful. Probably we can leave them to emulators only
> (but as I can see, PL011 emulator is going to be merged right into
> hypervisor. Will be there need for other emulators?).
> What I really want to ask: what do you thing about old good modules
> like ones in linux kernel? There will be no isolation, this is bad.
> But:
>  - you can load proprietary modules if you want to
>  - they are fast
>  - you can interface with them in a nativest way possible: just call a
> function

Proprietary modules are a legal minefield. They are best avoided even in
Linux. Fortunately, both EL0 apps and stubdoms could be proprietary.
Thus, especially if you have a requirement for running proprietary
code, it is key to do EL0 apps and/or stubdoms in Xen on ARM.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread Lars Kurth 

> On 11 May 2017, at 18:20, George Dunlap  wrote:
> 
> On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk
>  wrote:
>> Hi George,
>> 
>> On 11 May 2017 at 19:35, George Dunlap  wrote:
>>> Even better would be to skip the module-loading step entirely, and just
>>> compile proprietary code directly into your Xen binary.
>>> 
>>> Both solutions, unfortunately, are illegal.*
>> Look, I don't saying we want to produce closed-source modules or apps.
>> We want to write open source code. Just imagine, that certain header
>> files have some proprietary license (e.g. some device interface
>> definition and this interface is IP of company which developed it).
>> AFAIK, it can't be included into Xen distribution. I thought, that it
>> can be included in some module with different (but still open source)
>> license.  But if you say that it can't... Then I don't know. It is out
>> of my competence. I'm not lawyer also.
> 
> I see.  That's good to know, but it doesn't change the legal aspect of
> things. :-0

The legal issues would be similar to those with Linux Kernel Modules. For more 
information, see 
http://www.ifross.org/en/artikel/license-incompatibility-and-linux-kernel-modules-reloaded

Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread George Dunlap 
On Thu, May 11, 2017 at 6:14 PM, Volodymyr Babchuk
 wrote:
> Hi George,
>
> On 11 May 2017 at 19:35, George Dunlap  wrote:
>> Even better would be to skip the module-loading step entirely, and just
>> compile proprietary code directly into your Xen binary.
>>
>> Both solutions, unfortunately, are illegal.*
> Look, I don't saying we want to produce closed-source modules or apps.
> We want to write open source code. Just imagine, that certain header
> files have some proprietary license (e.g. some device interface
> definition and this interface is IP of company which developed it).
> AFAIK, it can't be included into Xen distribution. I thought, that it
> can be included in some module with different (but still open source)
> license.  But if you say that it can't... Then I don't know. It is out
> of my competence. I'm not lawyer also.

I see.  That's good to know, but it doesn't change the legal aspect of
things. :-0

It used to be held that the information contained in headers --
constants, interface definitions, and so on -- weren't copyrightable;
in which case you could just include the header (or a modified version
of it) without any problems.  Unfortunately Oracle v Google may have
changed that.  But you'd have to ask a lawyer about that...

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread George Dunlap 
On Thu, May 11, 2017 at 6:14 PM, George Dunlap  wrote:
> yourself at a risk of meeting a guy like Patrick McHardy[1], a private
> individual with copyright on the Linux kernel

This should be "copyright on *code in the* Linux Kernel".  Obviously
he doesn't own a copyright on the whole thing, just a decent chunk of
it.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread Volodymyr Babchuk 
Hi George,

On 11 May 2017 at 19:35, George Dunlap  wrote:
> Even better would be to skip the module-loading step entirely, and just
> compile proprietary code directly into your Xen binary.
>
> Both solutions, unfortunately, are illegal.*
Look, I don't saying we want to produce closed-source modules or apps.
We want to write open source code. Just imagine, that certain header
files have some proprietary license (e.g. some device interface
definition and this interface is IP of company which developed it).
AFAIK, it can't be included into Xen distribution. I thought, that it
can be included in some module with different (but still open source)
license.  But if you say that it can't... Then I don't know. It is out
of my competence. I'm not lawyer also.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread George Dunlap 
On 11/05/17 16:35, Julien Grall wrote:
> Renaming the subject + adding more people in the conversation as this is
> not related to only ARM anymore.
> 
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini 
>> wrote:
>>> I just want to point out that the comparision with tasklets is not
>>> helpful. Tasklets involve the idle vcpu, which we are trying to step
>>> away
>>> from because it increases irq latency. Tasklets don't provide any
>>> isolation. The context switch model for the idle vcpu and for EL0 apps
>>> is different, thus it has a different cost.
>>>
>>> I think we shouldn't mention tasklets in this thread any longer.
>> Yep, you are right. Let's forget about tasklets and focus on EL0 apps.
>>
>> I want summarize political (opposed to technical) part of the discussion.
>>
>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>> hypervisor. Because when it comes to embedded and automotive, there
>> arise some ugly things, that are needed at hypervisor level:
>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>> MSHIELD with deeply proprietary license),

If you're going to use a deeply proprietary TEE mediator, then you need
to find yourself a deeply proprietary hypervisor to go along with it --
either one you pay a license fee for or one you develop yourself.  It
would almost certainly be cheaper to improve the open-source one than to
do either of those.

Or you can try mixing the two and see what happens; but that doesn't
seem like a very sound legal strategy to me.

>> ...some [things can't be included in hypervisor] because of code
>> size or complexity.

Sorry, just to be clear: below you mentioned modules as a solution, and
given the context this would be included.  So can you expand on what you
mean that there are things that 1) can't be included in the hypervisor
because of code size or complexity, but for which 2) loadable modules
would be a suitable solution?

>> And we can't run
>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>> some cases they are insecure, in some cases they just don't fit at
>> all.
>> On other hand you consider EL0 apps as ideal host for emulators only.
>> I can see your point, because XEN was always viewed as hypervisor for
>> servers.
>> But servers have different requirements in comparison to embedded
>> applications. Traditional servers does not use hardware accelerated
>> video decoders, they don't need to disable cpu's or scale frequencies
>> to preserve energy (okay, they need to, but it is not as pressing, as
>> on battery-powered device), there almost no proprietary code (or even
>> proprietary blobs, argh!).
>> Looks like virtualization on embedded is the next big thing. Linux
>> kernel was able to satisfy both parties. I hope that XEN can do the
>> same.

For many of these, there are probably technical solutions that we could
come up with that would allow proprietary content (such as video
decoders ) that would have suitable performance without needing access
to the Xen address space.

Maybe I'm just not familiar with things, but it's hard for me to imagine
why you'd need proprietary blobs to disable cpus or scale frequency.
Are these really such complex activities that it's worth investing
thousands of hours of developer work into developing proprietary
solutions that you license?

Loading proprietary modules into Linux is as illegal as it would be in
Xen.  Many people obviously do it anyway, but you are really putting
yourself at a risk of meeting a guy like Patrick McHardy[1], a private
individual with copyright on the Linux kernel who by some estimates has
made almost EUR 2m in the last few years suing companies for GPL violations.

 -George

[1] https://lwn.net/Articles/721458/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))

2017-05-11 Thread George Dunlap 
On 11/05/17 16:35, Julien Grall wrote:
> On 11/05/17 16:19, Volodymyr Babchuk wrote:
>> Hi Stefano,
>>
>> On 10 May 2017 at 21:24, Stefano Stabellini 
>> wrote:
>>> I just want to point out that the comparision with tasklets is not
>>> helpful. Tasklets involve the idle vcpu, which we are trying to step
>>> away
>>> from because it increases irq latency. Tasklets don't provide any
>>> isolation. The context switch model for the idle vcpu and for EL0 apps
>>> is different, thus it has a different cost.
>>>
>>> I think we shouldn't mention tasklets in this thread any longer.
>> Yep, you are right. Let's forget about tasklets and focus on EL0 apps.
>>
>> I want summarize political (opposed to technical) part of the discussion.
>>
>> We, here at EPAM, viewed EL0 apps primarily as a way to extend
>> hypervisor. Because when it comes to embedded and automotive, there
>> arise some ugly things, that are needed at hypervisor level:
>> TEE mediators (OP-TEE is a good TEE, but for example there is TI's
>> MSHIELD with deeply proprietary license), device drivers for vcopros,
>> device drivers for cpufreq, and so on.
>> Some of this things can't be included in hypervisor due to legal
>> issues, some - because of code size or complexity. And we can't run
>> them in stubdoms, because stubdoms are slow for certain use-cases, in
>> some cases they are insecure, in some cases they just don't fit at
>> all.
>>
>> On other hand you consider EL0 apps as ideal host for emulators only.
>> I can see your point, because XEN was always viewed as hypervisor for
>> servers.
>> But servers have different requirements in comparison to embedded
>> applications. Traditional servers does not use hardware accelerated
>> video decoders, they don't need to disable cpu's or scale frequencies
>> to preserve energy (okay, they need to, but it is not as pressing, as
>> on battery-powered device), there almost no proprietary code (or even
>> proprietary blobs, argh!).
>> Looks like virtualization on embedded is the next big thing. Linux
>> kernel was able to satisfy both parties. I hope that XEN can do the
>> same.
>>
>> So, going back to EL0 apps. Honestly, I'd prefer not to use them as
>> extension mechanism. Yes, they provide isolation, but interfacing with
>> them will be painful. Probably we can leave them to emulators only
>> (but as I can see, PL011 emulator is going to be merged right into
>> hypervisor. Will be there need for other emulators?).
>> What I really want to ask: what do you thing about old good modules
>> like ones in linux kernel? There will be no isolation, this is bad.
>> But:
>>  - you can load proprietary modules if you want to
>>  - they are fast
>>  - you can interface with them in a nativest way possible: just call a
>> function

Even better would be to skip the module-loading step entirely, and just
compile proprietary code directly into your Xen binary.

Both solutions, unfortunately, are illegal.*

 -George

* I am not a lawyer, and this is not legal advice; but see this
presentation for a bit more information:
http://www.kroah.com/log/linux/ols_2006_keynote.html


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel