Re: [GSoC] project proposal
On Wed, Apr 22, 2015 at 9:51 AM, Catalin Vasile catalinvasil...@gmail.com wrote: On Wed, Apr 22, 2015 at 11:20 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Apr 21, 2015 at 04:07:56PM +0200, Paolo Bonzini wrote: On 21/04/2015 16:07, Catalin Vasile wrote: I don't get the part with getting cryptodev upstream. I don't know what getting cryptodev upstream actually implies. From what I know cryptodev is done (is a functional project) that was rejected in the Linux Kernel and there isn't actually way to get it upstream. Yes, I agree. The limitations of AF_ALG need to addressed somehow, so what is the next step? Stefan If we want a mainstream userspace backend that could interact with a lot of crypto engines, we could use OpenSSL (it can actually use cryptodev and AF_ALG as engines). For now, until mid June (my diploma project presentation) I still want to use vhost as a backend for the sole purpose of having a finished backend which now I have a good grasp upon. I understand. Once you have a first approximation of the new virtio crypto device interface, I suggest continuing the discussion with the VIRTIO working group: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio#feedback If you send a virtio spec proposal you can get feedback. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On 22/04/2015 10:51, Catalin Vasile wrote: If we want a mainstream userspace backend that could interact with a lot of crypto engines, we could use OpenSSL (it can actually use cryptodev and AF_ALG as engines). For now, until mid June (my diploma project presentation) I still want to use vhost as a backend for the sole purpose of having a finished backend which now I have a good grasp upon. If the finished work would be good enough work to be merged upstream will be talked later. As a GSoC project, OpenSSL as a backend would continue the virtio-crypto development, as it's not uncommon to have multiple types of backends. The current work on virtio-crypto qemu and guest module is pretty backend agnostic, and could allow future development(use of other backends and other features). OpenSSL's license is not compatible with QEMU, hence the suggestion of using gnutls. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
I found my way through it's API. http://www.gnutls.org/manual/gnutls.html#Cryptographic-API Does anyone know if it has one shot givencrypt (generate IV and encrypt as one job)? I see an option to get random data, but I was thinking if there is an one shot option. On Wed, Apr 22, 2015 at 4:43 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 22/04/2015 10:51, Catalin Vasile wrote: If we want a mainstream userspace backend that could interact with a lot of crypto engines, we could use OpenSSL (it can actually use cryptodev and AF_ALG as engines). For now, until mid June (my diploma project presentation) I still want to use vhost as a backend for the sole purpose of having a finished backend which now I have a good grasp upon. If the finished work would be good enough work to be merged upstream will be talked later. As a GSoC project, OpenSSL as a backend would continue the virtio-crypto development, as it's not uncommon to have multiple types of backends. The current work on virtio-crypto qemu and guest module is pretty backend agnostic, and could allow future development(use of other backends and other features). OpenSSL's license is not compatible with QEMU, hence the suggestion of using gnutls. Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On Tue, Apr 21, 2015 at 04:07:56PM +0200, Paolo Bonzini wrote: On 21/04/2015 16:07, Catalin Vasile wrote: I don't get the part with getting cryptodev upstream. I don't know what getting cryptodev upstream actually implies. From what I know cryptodev is done (is a functional project) that was rejected in the Linux Kernel and there isn't actually way to get it upstream. Yes, I agree. The limitations of AF_ALG need to addressed somehow, so what is the next step? Stefan pgpDV1dGiX8CC.pgp Description: PGP signature
Re: [GSoC] project proposal
On Tue, Apr 21, 2015 at 05:24:55PM +0300, Catalin Vasile wrote: Can you give me more details on GnuTLS? I'm going through some documentation and code and I see that it doesn't actually have separate encryption and authentication primitives. gnutls is a natural choice because QEMU already uses it for TLS, but if it doesn't support the primitives you need, then AF_ALG could be used directly. http://www.gnutls.org/manual/gnutls.html#Using-GnuTLS-as-a-cryptographic-library Stefan pgpucapBiwS6o.pgp Description: PGP signature
Re: [GSoC] project proposal
On Wed, Apr 22, 2015 at 11:20 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Apr 21, 2015 at 04:07:56PM +0200, Paolo Bonzini wrote: On 21/04/2015 16:07, Catalin Vasile wrote: I don't get the part with getting cryptodev upstream. I don't know what getting cryptodev upstream actually implies. From what I know cryptodev is done (is a functional project) that was rejected in the Linux Kernel and there isn't actually way to get it upstream. Yes, I agree. The limitations of AF_ALG need to addressed somehow, so what is the next step? Stefan If we want a mainstream userspace backend that could interact with a lot of crypto engines, we could use OpenSSL (it can actually use cryptodev and AF_ALG as engines). For now, until mid June (my diploma project presentation) I still want to use vhost as a backend for the sole purpose of having a finished backend which now I have a good grasp upon. If the finished work would be good enough work to be merged upstream will be talked later. As a GSoC project, OpenSSL as a backend would continue the virtio-crypto development, as it's not uncommon to have multiple types of backends. The current work on virtio-crypto qemu and guest module is pretty backend agnostic, and could allow future development(use of other backends and other features). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
In those examples algorithms are used with standard protocols, not with standalone algorithms. CryptoAPI itself offers basic primitives such as encryption and authentication which can be combined however you like. Some combinations care result in other protocol implementations as well. On Wed, Apr 22, 2015 at 11:27 AM, Stefan Hajnoczi stefa...@gmail.com wrote: On Tue, Apr 21, 2015 at 05:24:55PM +0300, Catalin Vasile wrote: Can you give me more details on GnuTLS? I'm going through some documentation and code and I see that it doesn't actually have separate encryption and authentication primitives. gnutls is a natural choice because QEMU already uses it for TLS, but if it doesn't support the primitives you need, then AF_ALG could be used directly. http://www.gnutls.org/manual/gnutls.html#Using-GnuTLS-as-a-cryptographic-library Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
I don't get the part with getting cryptodev upstream. I don't know what getting cryptodev upstream actually implies. From what I know cryptodev is done (is a functional project) that was rejected in the Linux Kernel and there isn't actually way to get it upstream. On Tue, Mar 31, 2015 at 8:14 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. My suggestion is to work on the gnutls driver. Then, if you have time left, get cryptodev upstream (it can be part of your GSoC project plan). That approach is more beneficial in the long run. It will allow other applications to use the Crypto API too. vhost is good for exploiting kernel-only functionality (usually due to security/reliability boundaries). In this case the only reason for vhost is that the userspace API isn't ready yet. Use the opportunity to contribute to that effort instead of working around it. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
Can you give me more details on GnuTLS? I'm going through some documentation and code and I see that it doesn't actually have separate encryption and authentication primitives. P.S. I have excluded Kim Philiphs from this mail because the mailing list doesn't allow me to send e-mails to users not included on the mailing list subscribers. On Tue, Mar 31, 2015 at 8:14 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. My suggestion is to work on the gnutls driver. Then, if you have time left, get cryptodev upstream (it can be part of your GSoC project plan). That approach is more beneficial in the long run. It will allow other applications to use the Crypto API too. vhost is good for exploiting kernel-only functionality (usually due to security/reliability boundaries). In this case the only reason for vhost is that the userspace API isn't ready yet. Use the opportunity to contribute to that effort instead of working around it. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
I don't get the part with getting cryptodev upstream. I don't know what getting cryptodev upstream actually implies. From what I know cryptodev is done (is a functional project) that was rejected in the Linux Kernel and there isn't actually way to get it upstream. On Tue, Mar 31, 2015 at 8:14 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. My suggestion is to work on the gnutls driver. Then, if you have time left, get cryptodev upstream (it can be part of your GSoC project plan). That approach is more beneficial in the long run. It will allow other applications to use the Crypto API too. vhost is good for exploiting kernel-only functionality (usually due to security/reliability boundaries). In this case the only reason for vhost is that the userspace API isn't ready yet. Use the opportunity to contribute to that effort instead of working around it. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On 21/04/2015 16:07, Catalin Vasile wrote: I don't get the part with getting cryptodev upstream. I don't know what getting cryptodev upstream actually implies. From what I know cryptodev is done (is a functional project) that was rejected in the Linux Kernel and there isn't actually way to get it upstream. Yes, I agree. Paolo On Tue, Mar 31, 2015 at 8:14 PM, Stefan Hajnoczi stefa...@gmail.com mailto:stefa...@gmail.com wrote: On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini pbonz...@redhat.com mailto:pbonz...@redhat.com wrote: On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. My suggestion is to work on the gnutls driver. Then, if you have time left, get cryptodev upstream (it can be part of your GSoC project plan). -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. My suggestion is to work on the gnutls driver. Then, if you have time left, get cryptodev upstream (it can be part of your GSoC project plan). That approach is more beneficial in the long run. It will allow other applications to use the Crypto API too. vhost is good for exploiting kernel-only functionality (usually due to security/reliability boundaries). In this case the only reason for vhost is that the userspace API isn't ready yet. Use the opportunity to contribute to that effort instead of working around it. Stefan -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On 19/03/2015 19:38, Catalin Vasile wrote: I have submitted my application on the official GSoC site. Do I also have to submit it on this discussion list or anywhere else? No, I can see the application. Thanks! Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
I have submitted my application on the official GSoC site. Do I also have to submit it on this discussion list or anywhere else? On Wed, Mar 18, 2015 at 10:59 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. In any case, just put all the justification in your application. Thanks for participating to QEMU's GSoC! Paolo gnutls can use cryptodev and AF_ALG as crypto engines. From some benchmarks (that can also be found on cryptodev's webpage) you can see AF_ALG has a lot overhead over a standalone misc/char device. On Wed, Mar 18, 2015 at 6:42 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 17:01, Catalin Vasile wrote: To be more exact, I want to make a virtio-crypto device to emulate a virtual cryptographic offloading device that will send jobs from the guest to a vhost that will process the jobs. This mechanism will link CryptoAPI from the guest to the CryptoAPI from the host. This way, whatever it's beneath CryptoAPI from the host will be used as offloading for the guest. Is there a mentor interested in getting involved in this kind of project? I think it's very likely that you'll find a mentor. Please submit a proposal, also detailing the advantage of vhost over a userspace solution (using any of gnutls, AF_ALG, cryptodev). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GSoC] project proposal
Hi, My name is Catalin Vasile and I want to participate with a project for qemu at GSoC. From what I understand from the rules, I can participate with things I could also use for my college projects. This is my last bachelor year and I'm doing my diploma project, which is related to virtualization, more specific qemu-kvm. I'm trying to do a paravirtualized device using virtio and vhost. I've already done some work. To be more exact, I want to make a virtio-crypto device to emulate a virtual cryptographic offloading device that will send jobs from the guest to a vhost that will process the jobs. This mechanism will link CryptoAPI from the guest to the CryptoAPI from the host. This way, whatever it's beneath CryptoAPI from the host will be used as offloading for the guest. Is there a mentor interested in getting involved in this kind of project? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On 18/03/2015 17:01, Catalin Vasile wrote: To be more exact, I want to make a virtio-crypto device to emulate a virtual cryptographic offloading device that will send jobs from the guest to a vhost that will process the jobs. This mechanism will link CryptoAPI from the guest to the CryptoAPI from the host. This way, whatever it's beneath CryptoAPI from the host will be used as offloading for the guest. Is there a mentor interested in getting involved in this kind of project? I think it's very likely that you'll find a mentor. Please submit a proposal, also detailing the advantage of vhost over a userspace solution (using any of gnutls, AF_ALG, cryptodev). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
cryptodev is not merged into upstream from what I know. gnutls can use cryptodev and AF_ALG as crypto engines. From some benchmarks (that can also be found on cryptodev's webpage) you can see AF_ALG has a lot overhead over a standalone misc/char device. On Wed, Mar 18, 2015 at 6:42 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 17:01, Catalin Vasile wrote: To be more exact, I want to make a virtio-crypto device to emulate a virtual cryptographic offloading device that will send jobs from the guest to a vhost that will process the jobs. This mechanism will link CryptoAPI from the guest to the CryptoAPI from the host. This way, whatever it's beneath CryptoAPI from the host will be used as offloading for the guest. Is there a mentor interested in getting involved in this kind of project? I think it's very likely that you'll find a mentor. Please submit a proposal, also detailing the advantage of vhost over a userspace solution (using any of gnutls, AF_ALG, cryptodev). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC] project proposal
On 18/03/2015 18:05, Catalin Vasile wrote: cryptodev is not merged into upstream from what I know. Yes, but QEMU runs on non-Linux platforms too. Of course doing vhost+driver or gnutls+driver would be already more than enough for the summer. In any case, just put all the justification in your application. Thanks for participating to QEMU's GSoC! Paolo gnutls can use cryptodev and AF_ALG as crypto engines. From some benchmarks (that can also be found on cryptodev's webpage) you can see AF_ALG has a lot overhead over a standalone misc/char device. On Wed, Mar 18, 2015 at 6:42 PM, Paolo Bonzini pbonz...@redhat.com wrote: On 18/03/2015 17:01, Catalin Vasile wrote: To be more exact, I want to make a virtio-crypto device to emulate a virtual cryptographic offloading device that will send jobs from the guest to a vhost that will process the jobs. This mechanism will link CryptoAPI from the guest to the CryptoAPI from the host. This way, whatever it's beneath CryptoAPI from the host will be used as offloading for the guest. Is there a mentor interested in getting involved in this kind of project? I think it's very likely that you'll find a mentor. Please submit a proposal, also detailing the advantage of vhost over a userspace solution (using any of gnutls, AF_ALG, cryptodev). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
