[GSoC] project proposal

[GSoC] project proposal

[Catalin Vasile]

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?

Re: [GSoC] project proposal

[Paolo Bonzini]

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

Re: [GSoC] project proposal

[Catalin Vasile]

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 <pbonzini@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

Re: [GSoC] project proposal

[Paolo Bonzini]

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 <pbonzini@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [GSoC] project proposal

[Catalin Vasile]

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 <pbonzini@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 <pbonzini@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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: [GSoC] project proposal

[Paolo Bonzini]

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

Re: [GSoC] project proposal

[Stefan Hajnoczi]

On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini <pbonzini@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

Re: [GSoC] project proposal

[Paolo Bonzini]

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 <stefanha@gmail.com
> <mailto:stefanha@gmail.com>> wrote:
> 
>     On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini <pbonzini@redhat.com
>     <mailto:pbonzini@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).

Re: [GSoC] project proposal

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [GSoC] project proposal

[Catalin Vasile]

On Wed, Apr 22, 2015 at 11:20 AM, Stefan Hajnoczi <stefanha@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).

Re: [GSoC] project proposal

[Paolo Bonzini]

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

Re: [GSoC] project proposal

[Catalin Vasile]

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 <pbonzini@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

Re: [GSoC] project proposal

[Stefan Hajnoczi]

On Wed, Apr 22, 2015 at 9:51 AM, Catalin Vasile
<catalinvasile92@gmail.com> wrote:
> On Wed, Apr 22, 2015 at 11:20 AM, Stefan Hajnoczi <stefanha@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

Re: [GSoC] project proposal

[Catalin Vasile]

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 <stefanha@gmail.com> wrote:
> On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini <pbonzini@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

Re: [GSoC] project proposal

[Catalin Vasile]

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 <stefanha@gmail.com> wrote:
> On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini <pbonzini@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

Re: [GSoC] project proposal

[Catalin Vasile]

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 <stefanha@gmail.com> wrote:
> On Wed, Mar 18, 2015 at 8:59 PM, Paolo Bonzini <pbonzini@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

Re: [GSoC] project proposal

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 492 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [GSoC] project proposal

[Catalin Vasile]

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 <stefanha@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