-
Notifications
You must be signed in to change notification settings - Fork 12
perf: embed Hmac in cookie_checker to eliminate make_cookie malloc #22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -9,6 +9,7 @@ | |||||||||||||||||||
| #define _WG_COOKIE_H | ||||||||||||||||||||
|
|
||||||||||||||||||||
| #include "messages.h" | ||||||||||||||||||||
| #include "wolfcrypt_glue.h" | ||||||||||||||||||||
| #include <linux/rwsem.h> | ||||||||||||||||||||
|
|
||||||||||||||||||||
| struct wg_peer; | ||||||||||||||||||||
|
|
@@ -19,6 +20,10 @@ struct cookie_checker { | |||||||||||||||||||
| u8 message_mac1_key[NOISE_SYMMETRIC_KEY_LEN]; | ||||||||||||||||||||
| u64 secret_birthdate; | ||||||||||||||||||||
| struct rw_semaphore secret_lock; | ||||||||||||||||||||
| /* Scratch buffer for make_cookie() — avoids per-call kmalloc of the | ||||||||||||||||||||
|
||||||||||||||||||||
| /* Scratch buffer for make_cookie() — avoids per-call kmalloc of the | |
| /* Scratch buffer for make_cookie() - avoids per-call allocation of the |
Copilot
AI
Apr 17, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Embedding an ~832-byte struct Hmac directly into struct cookie_checker increases the size of what is likely a frequently-touched structure, which can degrade cache locality for unrelated cookie-checking operations. To keep the “allocate once, reuse many” benefit without inflating the hot struct, consider storing struct Hmac *make_cookie_hmac (or a dedicated scratch sub-struct) allocated once at device init/teardown; this avoids per-call allocation while reducing steady-state cache footprint.
| /* Scratch buffer for make_cookie() — avoids per-call kmalloc of the | |
| * 832-byte Hmac struct. Used only while secret_lock is held for write. | |
| */ | |
| struct Hmac make_cookie_hmac; | |
| /* Scratch buffer for make_cookie(); allocate once during init and reuse | |
| * to avoid per-call allocation without inflating this hot structure. | |
| * Used only while secret_lock is held for write. | |
| */ | |
| struct Hmac *make_cookie_hmac; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Holding
secret_lockas a write-lock across the full HMAC computation blocks all potential readers ofsecret_lockfor the duration ofwc_HmacInit/Update/Final, not just secret refresh. Under sustained rate-limited traffic (e.g., an active attacker), this can amplify contention and potentially delay other threads that only need read access to the cookie secret. A more scalable approach is to keepsecret_locksemantics focused on guardingchecker->secret(e.g., takedown_read, copychecker->secretinto a small stack/local buffer likeu8 secret[NOISE_HASH_LEN], thenup_read), and separately serialize access tomake_cookie_hmacwith a dedicated mutex/lock; this preserves the “no per-call allocation” goal without turning every cookie generation into a global write-side stop-the-world for the checker.