- "Neil Horman" wrote:
> On Mon, Dec 13, 2010 at 12:24:34PM -0500, Miloslav Trmac wrote:
> > - "Neil Horman" wrote:
> > > +static int rng_recvmsg(struct kiocb *unused, struct socket
> *sock,
> > > + struct msghdr *msg, s
- "Neil Horman" wrote:
> +static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
> + struct msghdr *msg, size_t len, int flags)
> +{
> + struct sock *sk = sock->sk;
> + struct alg_sock *ask = alg_sk(sk);
> + struct rng_ctx *ctx = ask->private;
> +
- "Eric Paris" wrote:
> On Tue, 2010-11-23 at 13:50 +0100, Miloslav Trmač wrote:
> > Collect audited crypto operations in a list, because a single _exit()
> > can cause several AF_ALG sockets to be closed, and each needs to be
> > audited.
> >
> > Add the AUDIT_CRYPTO_OP field so that crypto
Hello,
attached is an user-space patch that adds support for auditing uses of the
AF_ALG protocol family developed by Herbert Xu to provide user-space access to
kernel crypto accelerators. Kernel patches will follow.
One new record is defined: AUDIT_CRYPTO_USERSPACE_OP. An audited event is
al
- "Christoph Hellwig" wrote:
> On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote:
> > - Don't use a FD for associated data that is limited to 16? bytes
> >
> > - Don't use file descriptors for input data at all, if it makes the
>
- "Herbert Xu" wrote:
> On Tue, Sep 07, 2010 at 10:34:25AM -0400, Miloslav Trmac wrote:
> >
> > > > > /* These may also be set through sendmsg(2) cmsgs. */
> > > > > op = ALG_AEAD_OP_ENCRYPT;
> > > >
- "Herbert Xu" wrote:
> On Tue, Sep 07, 2010 at 07:27:47AM -0400, Miloslav Trmac wrote:
> > Hello,
> > - "Herbert Xu" wrote:
> > > First of all let's have a quick look at what the user-space side
> > > looks like for AEAD:
> &
Hello,
- "Herbert Xu" wrote:
> First of all let's have a quick look at what the user-space side
> looks like for AEAD:
>
> /* Each listen call generates one or more fds for input/output
>* that behave like pipes.
>*/
> listen(tfmfd, 0);
> /* fd for encryption
- "Kyle Moffett" wrote:
> On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac wrote:
> > - "Herbert Xu" wrote:
> >> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >> > I have seriously considered the keyring API, and this
- "Herbert Xu" wrote:
> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >
> > I can see almost no overlap between the two sets of requirements.
> Probably the only common use case is handling session keys (e.g. keys
> used in a kerberos tic
- "Herbert Xu" wrote:
> Thanks for the updated patch-set. It does indeed fulfil some
> of the requirements raised earlier.
>
> However, as far as I can see this still does not address the
> extensibility. For example, say we want add an interface to
> allow the xoring of two arbitrary data
- "Pavel Machek" wrote:
> > * Advanced crypto module for OSPP for Common Criteria requires OS services
> > implementing several low-level crypto algorithms (e.g. AES, RSA). This
> > requires the separation of crypto services from the consumer of those
> > services. (The threat model is
- "Shirish Pargaonkar" wrote:
> Instead of determining and allocating a char array for use during usage of
> crypto_shash_* calls, would like to instead dynamically
> allocate (and free) storage for the duration of crypto calculation
> (crypto_shash_init,
> crypto_shash_update, and crypto_shas
- "Arnd Bergmann" wrote:
> On Friday 20 August 2010 10:45:43 Miloslav Trmač wrote:
> >
> > Major changes since the previous post:
> > * "struct nlattr"-based extensible attributes used for extensibility
> > of most operations, both for input and output attributes
>
> The API here looks ov
- "Kyle Moffett" wrote:
> On Fri, Aug 20, 2010 at 04:45, Miloslav Trmač
> wrote:
> > * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key
> > material inside the kernel, load a plaintext key, unwrap a key, or
> > derive a key. Similarly the key material can be copied out
- "Stefan Richter" wrote:
> Miloslav Trmač wrote:
> > --- /dev/null
> > +++ b/include/linux/ncr.h
> [...]
> > +struct ncr_session_input_data {
> > + const void __user *data;
> > + __kernel_size_t data_size;
> > +};
>
> Why not using fixed-size fit-all members?
>
> struct ncr_session_inpu
- "Stefan Richter" wrote:
> Miloslav Trmač wrote:
> > --- /dev/null
> > +++ b/crypto/userspace/utils.c
> [...]
> > +#ifdef CONFIG_COMPAT
> > +/* max() is too clever for compile-time constants */
> > +#define CONST_MAX(A, B) ((A) > (B) ? (A) : (B))
> > +
> > +#define MAX_SESSION_INPUT_DATA_SIZE
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 10:06:05PM -0400, Miloslav Trmac wrote:
> > - "Neil Horman" wrote:
> > > Ok, well, I suppose we're just not going to agree on this. I don't know
> > > how
> > > el
Hello,
thanks your review and all comments.
- "Linus Walleij" wrote:
>For internal keys, a function for compare of HMAC function results
>could improve security considerably.
I'm afraid I don't understand what this refers to. Can you give me an example?
(You already can use OP_VERI
- "Neil Horman" wrote:
> Ok, well, I suppose we're just not going to agree on this. I don't know how
> else to argue my case, you seem to be bent on re-inventing the wheel instead
> of
> using what we have. Good luck.
Well, I basically spent yesterday learning about netlink and looking how
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 03:10:12PM -0400, Steve Grubb wrote:
> > > Can you ennumerate here what FIPS and Common Criteria mandate be presented
> > > in the audit logs?
> >
> > Who did what to whom at what time and what was the outcome. In the case of
> > configuration
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 02:19:59PM -0400, Miloslav Trmac wrote:
> > - "Neil Horman" wrote:
> > It _doesn't matter_ that I don't receive a response. I have caused
> an operation in the kernel and the requested a
- "Miloslav Trmac" wrote:
> - "Neil Horman" wrote:
> > Likewise, matching requests and responses in a multi-threaded program is
> > also an
> > already solved issue in multiple ways. The use of multiple sockets, in a 1
> > per
> >
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 11:36:16AM -0400, Miloslav Trmac wrote:
> > I think it would be useful to separate thinking about the data
> format and about the transmission mechanism. ioctl() can quite well
> be used to carry "netlink-like
- "Herbert Xu" wrote:
> On Tue, Aug 10, 2010 at 02:19:59PM -0400, Miloslav Trmac wrote:
> >
> > 2) simplicity and reliability: you are downplaying the overhead and
> synchronization necessary (potentially among multiple processes!) to
> simply receive a res
Hello,
- "Loc Ho" wrote:
> I had read or glance over the patch from "
> http://people.redhat.com/mitr/cryptodev-ncr/0002";. We have post a
> version of the CryptoDev over a year ago. Unfortunately, we did not
> got a chance to pick up again. In that process, Herbert Xu provides a
> number of c
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 12:57:43PM -0400, Miloslav Trmac wrote:
> >
> > - "Neil Horman" wrote:
> >
> > > On Tue, Aug 10, 2010 at 11:40:00AM -0400, Miloslav Trmac wrote:
> > > > - "Neil
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 11:40:00AM -0400, Miloslav Trmac wrote:
> > - "Neil Horman" wrote:
> > > On Tue, Aug 10, 2010 at 10:47:14AM -0400, Miloslav Trmac wrote:
> > > > - "Neil Horman" wrote:
>
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 10:47:14AM -0400, Miloslav Trmac wrote:
> > - "Neil Horman" wrote:
> > > On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> > > > The problem with the netlink approac
- "Neil Horman" wrote:
> On Mon, Aug 09, 2010 at 08:00:55PM -0400, Miloslav Trmac wrote:
> > Is the proposed interface acceptable in the general approach (enums
> for algorithms/operations, unions for parameters, session
> init/update/finalize)? With respect to
- "Neil Horman" wrote:
> On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> > > Thats why I had suggested the use of a netlink protocol to manage this
> > > kind
> > > of interface. There are other issue to manage there, but they're really
> > > not that big a deal, comparativel
- "Herbert Xu" wrote:
> On Thu, Aug 05, 2010 at 10:17:53PM +0200, Miloslav Trmač wrote:
> > Hello,
> > following is a patchset providing an user-space interface to the kernel
> > crypto
> > API. It is based on the older, BSD-compatible, implementation, but the
> > user-space interface is di
- "Neil Horman" wrote:
> On Thu, Aug 05, 2010 at 10:17:53PM +0200, Miloslav Trmač wrote:
> > Hello,
> > following is a patchset providing an user-space interface to the
> kernel crypto
> > API. It is based on the older, BSD-compatible, implementation, but
> the
> > user-space interface is dif
33 matches
Mail list logo
