linux-kernel - Re: RFC: Crypto API User-interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTikWRewCXdq3eeBMRQr3Ke7C2q42jnKqbKVwwpCH@mail.gmail.com>
Date:	Tue, 7 Sep 2010 16:49:46 +0200
From:	Nikos Mavrogiannopoulos <nmav@...tls.org>
To:	Herbert Xu <herbert@...dor.hengli.com.au>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: RFC: Crypto API User-interface

On Tue, Sep 7, 2010 at 4:11 PM, Herbert Xu <herbert@...dor.hengli.com.au> wrote:

>> > This is what I am proposing for the Crypto API user-interface.
>>
>> Can you explain why we would ever want a userspace interface to it?
>>
>> doing crypto in kernel for userspace consumers sis simply insane.
>> It's computational intensive code which has no business in kernel space
>> unless absolutely required (e.g. for kernel consumers).  In addition
>> to that adding the context switch overhead and address space transitions
>> is god awfull too.
>>
>> This all very much sounds like someone had far too much crack.
>
> FWIW I don't care about user-space using kernel software crypto at
> all.  It's the security people that do.

Then I'd suggest to not enforce your design over to people who have
thought and have interests on that. The NCR api which you rejected
(for not supporting kernel keyring - which your design also doesn't!),
has specific security goals and protects against specific threats.
This design here has been proposed by you quite many times in the past
and neither you, nor anyone else bothered implementing it. Now we have
two working implementations that offer user-space access to crypto
operations, (the openbsd cryptodev port), and NCR, but you discard
them and insist on a different design. Maybe yours is better (you have
to argue about that)... Probably I'd use it if it was there, but it
isn't.

regards,
Nikos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/