Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Loc Ho <lho@amcc.com>
Cc: Shasi Pulijala <spulijala@amcc.com>,
	herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support
Date: Wed, 14 May 2008 15:25:23 +0400	[thread overview]
Message-ID: <20080514112523.GA13073@2ka.mipt.ru> (raw)
In-Reply-To: <0CA0A16855646F4FA96D25A158E299D60472088A@SDCEXCHANGE01.ad.amcc.com>

On Tue, May 13, 2008 at 05:00:58PM -0700, Loc Ho (lho@amcc.com) wrote:
> Hi Herbert,
> 
> I am re-sending this email as I don't believe it got to the mailing
> list. Due to email problem, I am forward this patch on behalf of Shasi
> Pulijala who worked on this user space interface for Linux CryptoAPI.
> This should add support for OpenSSL. Please note that user of this patch
> musts patch OpenSSL. The OpenSSL patch can be found in OCF-Linux as this
> interface uses the same I/O control interface.

There is number of problems with this patchset:
1. codying style - likely the most harmless
2. on-stack allocation should be dropped where possible
3. session id can be generated as pointer to session, not via getting
	random bytes in a loop
4. linked list of in-flight session really does not scale
5. session destruction seems to be racy
6. do not use semaphores, mutex works ok here
7. lots of kmalloc/copy_*_user also much slower than single bigger
	allocation and sinegle copy_*_user
8. use kzalloc instead of kmalloc/memset
9. having pointer in structure shared between kernel and
	userspace is very wrong
10. userspace does not know about u32 and friends, use __u32 abd others
	instead

Please also provide a high-level description of the protocol used for
crypto processing.

-- 
	Evgeniy Polyakov

      parent reply	other threads:[~2008-05-14 11:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DB599F406D04E34389140B7D99C71B1B055EE51E@SDCEXCHANGE01.ad.amcc.com>
     [not found] ` <0CA0A16855646F4FA96D25A158E299D60301C29D@SDCEXCHANGE01.ad.amcc.com>
     [not found]   ` <DB599F406D04E34389140B7D99C71B1B055EE6B2@SDCEXCHANGE01.ad.amcc.com>
2008-05-14  0:00     ` [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support Loc Ho
2008-05-14 10:32       ` Sebastian Siewior
2008-05-14 11:03         ` Herbert Xu
2008-05-14 11:57           ` Userspace API proposal was: " Sebastian Siewior
2008-05-14 12:18             ` Evgeniy Polyakov
2008-05-14 15:40               ` Loc Ho
2008-05-14 16:09                 ` Evgeniy Polyakov
2008-05-15 20:16                   ` Linux CryptoAPI Userspace API proposal Loc Ho
2008-05-20  4:00                     ` Herbert Xu
2008-06-04 21:33                       ` Loc Ho
2008-05-14 15:04           ` [PATCH 1/1] RFC: Add CryptoAPI User Space Interface Support Loc Ho
2008-05-14 16:01             ` Herbert Xu
2008-05-14 11:25       ` Evgeniy Polyakov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080514112523.GA13073@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=herbert@gondor.apana.org.au \
    --cc=lho@amcc.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=spulijala@amcc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox