Date: Wed, 10 Jan 2018 23:54:19 -0800 From: Conrad Meyer <cem@freebsd.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Ranting about OCF / crypto(9) Message-ID: <CAG6CVpXdCT2=fdRXe77Q6m0126ZYPa%2Bx4AdH6NZ4Sk-fyztVAg@mail.gmail.com> In-Reply-To: <51883.1515656784@critter.freebsd.dk> References: <3790717.UIxaijsHl3@ralph.baldwin.cx> <51883.1515656784@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 10, 2018 at 11:46 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> --------
> In message <3790717.UIxaijsHl3@ralph.baldwin.cx>, John Baldwin writes:
>
>>- OCF is over flexible and overly broad.
>
> I would actually argue that it is neithe, quite the contrary.
>
> With the kernel-userland transition becoming more expensive, what
> we need is a DSL where you can put entire processing steps into the
> kernel, sort of like BPF but more general.
>
> Ideally, you should be able to push something like this into
> the kernel and have it executed in a single syscall:
>
> h = hash:sha256()
> b = file_buffer()
> f = open("/tmp/foo", "r")
> while f.read(b):
> h.input(b)
> return h.hex()
>
> BPF is the existence proof that stuff like this is both
> feasible and profitable, now we just need to take it to
> the next level.
>
> If we had a language like this, accept-filters whouldn't be
> necessary.
Sure, that's a great idea (well, aside from introducing a large attack
surface that the Linux folks have repeatedly discovered with eBPF).
But, embedding lua or something like lua in the kernel is completely
tangential to the problem of providing a good generic interface for
crypto hardware. Please don't hijack this thread with that
discussion.
Conrad
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXdCT2=fdRXe77Q6m0126ZYPa%2Bx4AdH6NZ4Sk-fyztVAg>