Switch BPF's digest to SHA256
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v2 Latest8 patches 11 repliesIn review
- v1 RFC6 patches 13 repliesSuperseded
Patches in v2 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/8 | crypto/sha256: Factor out the parts of base API that don't use shash_descinclude/ | +36 | 0 replies | |
| 2/8 | crypto/sha256: Export a sha256_{init,update,final}_direct() APIcrypto/ include/ include/ | +50 | 0 replies | |
| 3/8 | crypto/sha256: Build the SHA256 core separately from the crypto modulecrypto/ crypto/ crypto/ +1 more | +247 | 0 replies | |
| 4/8 | bpf: Use SHA256 instead of SHA1 for bpf digestsinclude/ init/ kernel/ | +12 | 0 replies | |
| 5/8 | bpf: Avoid copying the entire BPF program when hashing itkernel/ | +13 | 0 replies | |
| 6/8 | bpf: Rename fdinfo's prog_digest to prog_sha256kernel/ | +1 | 0 replies | |
| 7/8 | net: Rename TCA*BPF_DIGEST to ..._SHA256include/ include/ net/ +1 more | +4 | 5 replies | |
| 8/8 | crypto/testmgr: Allocate only the required output size for hash testscrypto/ | +5 | 5 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v2 yet.
Cover letter [PATCH v2 0/8] Switch BPF's digest to SHA256
I can imagine future uses for the new-in-4.10 BPF digest feature that would be problematic if malicious users could produce collisions, and SHA-1 is no longer consdiered to be collision-free. Even without needing collision resistance, SHA-1 is no longer recommended for new applications. Switch the BPF digest to SHA-256 instead.
The actual switchover is trivial. Most of this series consists of cleanups to the SHA256 code to make it usable as a standalone library (since BPF should not depend on crypto).
The cleaned up library is much more user-friendly than the SHA-1 code, so this also significantly tidies up the BPF digest code.
This is intended for 4.10. If this series misses 4.10 and nothing takes its place, then we'll have an unpleasant ABI stability situation.
NB: I would be happy to make parallel changes to the SHA-512 code if the crypto folks would like for me to do so. I haven't yet because I wanted to minimize churn. Also, the changes will be essentially identical to the SHA-256 changes and I want to get the latter reviewed first.
Andy Lutomirski (8):
crypto/sha256: Factor out the parts of base API that don't use
shash_desc
crypto/sha256: Export a sha256_{init,update,final}_direct() API crypto/sha256: Build the SHA256 core separately from the crypto module
bpf: Use SHA256 instead of SHA1 for bpf digests
bpf: Avoid copying the entire BPF program when hashing it
bpf: Rename fdinfo's prog_digest to prog_sha256
net: Rename TCA*BPF_DIGEST to ..._SHA256
crypto/testmgr: Allocate only the required output size for hash tests
crypto/Kconfig | 8 ++ crypto/Makefile | 1 + crypto/sha256_direct.c | 238 +++++++++++++++++++++++++++++++++++++ crypto/sha256_generic.c | 215 ++------------------------------- crypto/testmgr.c | 9 +- include/crypto/sha.h | 24 ++++ include/crypto/sha256_base.h | 58 +++++---- include/linux/filter.h | 11 +- include/uapi/linux/pkt_cls.h | 2 +- include/uapi/linux/tc_act/tc_bpf.h | 2 +- init/Kconfig | 1 + kernel/bpf/core.c | 63 +++------- kernel/bpf/syscall.c | 2 +- net/sched/act_bpf.c | 2 +- net/sched/cls_bpf.c | 2 +- 15 files changed, 343 insertions(+), 295 deletions(-) create mode 100644 crypto/sha256_direct.c
Signature · 1 line
2.9.3