x/sys/unix: support for AF_ALG sockets

[mdlayher]

During my recent netlink adventures, I learned of AF_ALG sockets on Linux. It appears these aren't currently exposed via x/sys/unix, and it'd be nice if they were.

I plan on using @elliotmr's work on adding AF_CAN sockets as reference, as discussed in #16188.

I'll give this a go, but if someone is already working on this, feel free to ping and we can collaborate!

[bradfitz]

Actually there was a discussion some time ago about trying to use this in the core for accelerated crypto on Linux without needing our own assembly.

One discussion is #4299 (comment) but that's not the one I'm thinking of. And I can't find it in my gmail either.

I'd be interested in reviewing!

I remember @agl was curious about the results/speed as well.

[mdlayher]

Good news: I got it working. One hangup is that I can't figure out why unix.Accept won't play nice with it, but doing syscall.Syscall(syscall.SYS_ACCEPT ...) works just fine. I am sure someone with more insight on x/sys/unix than me could probably help out with that.

Here's a quick and dirty prototype I did with it:

package main

import (
        "encoding/hex"
        "fmt"
        "io"
        "log"
        "os"
        "syscall"

        "golang.org/x/sys/unix"
)

func main() {
        log.SetFlags(log.Lshortfile)

        s, err := unix.Socket(unix.AF_ALG, unix.SOCK_SEQPACKET, 0)
        if err != nil {
                log.Fatal(err)
        }

        err = unix.Bind(s, &unix.SockaddrALG{
                Type: "hash",
                Name: "sha1",
        })
        if err != nil {
                log.Fatal(err)
        }

        nfd, _, e := syscall.Syscall(syscall.SYS_ACCEPT, uintptr(s), 0, 0)
        if e != 0 {
                log.Fatalf("errno:", e)
        }

        f := os.NewFile(nfd, "alg")
        io.Copy(f, os.Stdin)

        b := make([]byte, 20)
        if _, err := f.Read(b); err != nil {
                log.Fatal("read:", err)
        }

        fmt.Println(hex.EncodeToString(b))
}

Results:

$ echo "foo" | sha1sum                                                                                                                             
f1d2d2f924e986ac86fdf7b36c94bcdf32beec15  -
$ echo "foo" | ./afalg 
f1d2d2f924e986ac86fdf7b36c94bcdf32beec15

I can submit what I have now though and maybe someone will have some more insight on the matter.

[minux]

Unless a large quantity of data is involved (or we just splice(2) data without redundant copy?), crossing the user/kernel boundary will very likely kill much of the performance benefit. (That is, I think the right approach is for the kernel to expose VDSO calls to primitive crypto operations, rather than through netlink socket. But in that case, kernel bugs means updating buggy kernel provided crypto operations is much harder. Therefore, on balance, the best option is still do crypto in user space, unless we're talking TPM that wraps keys, but that's a different story altogether.)

[gopherbot]

CL https://golang.org/cl/36805 mentions this issue.

[mdlayher]

Unless a large quantity of data is involved (or we just splice(2) data
without redundant copy?), crossing the user/kernel boundary will very
likely kill much of the performance benefit.

Yep, this is my understanding and assumption as well. I just wanted to give this a try to see what could be done with it in Go.

[mdlayher]

Just for my own curiosity, I hacked up a quick and dirty SHA1 hash.Hash using AF_ALG. Each test opens and reads a kernel tarball I have saved locally. Here's some rough benchmarks:

$ du -h ~/tmp/linux-4.10-rc7.tar.xz 
90M     /home/matt/tmp/linux-4.10-rc7.tar.xz
$ sha1sum ~/tmp/linux-4.10-rc7.tar.xz 
85cdcad0c06eef66f805ecce353bec9accbeecc5  /home/matt/tmp/linux-4.10-rc7.tar.xz
$ go test -v -bench=.
=== RUN   TestSHA1Equal
result: 85cdcad0c06eef66f805ecce353bec9accbeecc5
--- PASS: TestSHA1Equal (0.33s)
BenchmarkCryptoSHA1-4             200000              8012 ns/op
BenchmarkAFALGSHA1-4              200000              8786 ns/op
PASS
ok      github.com/mdlayher/afalg       7.653s

Perhaps my naive benchmarks are flawed, but honestly, I'm pretty impressed to see that AF_ALG is anywhere close to the stdlib's optimized assembly implementation for linux/amd64.

Maybe this could be useful on other architectures outside of amd64? We can open another issue to look into it if needed. Just figured I would share since my curiosity got the best of me.