Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))
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))
[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))
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))
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))
[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. Regarding modules (#3):
Re: [Xen-devel] Modules support in Xen (WAS: Re: [ARM] Native application design and discussion (I hope))
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))
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 &c) 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))
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))
> 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))
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))
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))
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))
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 &c) 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))
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