News for hackers. Stuff that matters.
Re:WireGuard: next generation in-kernel modern VPN by nickpsecurity on Tuesday June 28, 2016 @11:39AM (#11994606)
It's faster. Performance usually matters more than security for most "security" products. ;) Having extra code in kernel is usually just asking for it. Here's one done closer to high-assurance principles that I'm sure the WireGuard scheme could be ported to:

http://genode-labs.com/publications/mikro-sina-2005.pdf

Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.

Re:WireGuard: next generation in-kernel modern VPN by zx2c4 on Tuesday June 28, 2016 @11:42AM (#11994633)
We'll actually be producing a Rust implementation for userspace. It'd be interesting to see that work ported back to kernelspace. Cool suggestions.
Re:WireGuard: next generation in-kernel modern VPN by nickpsecurity on Tuesday June 28, 2016 @11:45AM (#11994672)
That sounds good. What's its current implementation language?
Re:WireGuard: next generation in-kernel modern VPN by tptacek on Tuesday June 28, 2016 @03:18PM (#11996674)
It's Linux kernel resident. It's C code.
Re:WireGuard: next generation in-kernel modern VPN by nickpsecurity on Tuesday June 28, 2016 @03:45PM (#11996906)
Wow. Talk about overlooking the obvious. Thanks lol...
Re:WireGuard: next generation in-kernel modern VPN by viraptor on Tuesday June 28, 2016 @08:30PM (#11998677)
Maybe most likely, but not necessarily obvious. While there's no popular module for kernel written in something else than C (as far as I know), there are known ways to write working non-C modules.
Re:WireGuard: next generation in-kernel modern VPN by nickpsecurity on Wednesday June 29, 2016 @05:28AM (#12000435)
C was best assumption as 99+% chance it would be C. Yet, you are right in that I've seen device drivers for Linux done in Ada and ATS languages. It's why I usually don't assume but one was warranter here.