Date: Fri, 16 Dec 2016 21:11:01 +0100 From: Daniel Borkmann <daniel@...earbox.net> To: Kees Cook <keescook@...omium.org>, Sandra Escandor-O'Keefe <rvonflugel@...il.com> CC: "Reshetova, Elena" <elena.reshetova@...el.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, alexei.starovoitov@...il.com Subject: Re: Working on lib/test_bpf.c tests for eBPF constant blinding On 12/16/2016 09:02 PM, Kees Cook wrote: > On Fri, Dec 16, 2016 at 11:47 AM, Sandra Escandor-O'Keefe > <rvonflugel@...il.com> wrote: >> Excellent! Thanks for pointing to that write-up. So, what I can do is get to the point where I can manually perform the test to check inserted constants in >> eBPF instructions to verify that they are gone in the resulting eBPF JIT kernel code - this looks like I will first need to run the PoC attack that Elena created. From there, I'll have a better understanding of what to test. >> >> Would you approach it this way, or would you do something different? > > That sounds like how I'd start, yes. IIUC, you'll need to modify the > kernel so you can see the JIT in some way (this is, I think, what's > needed in test_ebpf.c), but I haven't looked at it very closely. > Daniel may have suggestions. If you're interested, you could ideally write a test suite for it under existing tools/testing/selftests/bpf/. If you enable JIT in the mode net.core.bpf_jit_enable=2, then you'll get the debug output dump in klog and under tools/net/ you have bpf_jit_disasm tool that you could use to examine it. This could likely be automated in a tool for various test inputs, but probably needs to have some arch specific code to make sense out of it. There's also lib/test_bpf.c, if it's not too much complexity, something could also be placed there for checking the image directly. >> Sandra >> >> Original Message >> From: keescook@...omium.org >> Sent: December 16, 2016 3:28 PM >> To: rvonflugel@...il.com >> Cc: kernel-hardening@...ts.openwall.com; elena.reshetova@...el.com; daniel@...earbox.net >> Subject: Re: [kernel-hardening] Working on lib/test_bpf.c tests for eBPF constant blinding > > As a side-note on email conventions, I'd recommend in-line replies and > quoting, which makes technical discussion much easier to follow (i.e. > don't top-post, etc). > > -Kees > >> On Fri, Dec 16, 2016 at 9:13 AM, Sandra Escandor-O'Keefe >> <rvonflugel@...il.com> wrote: >>> I'm interested in starting on a bit of linux kernel development, and also >>> contributing to something security related for the kernel. I was looking at >>> the projects listed in the TODO of >>> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project and "Write >>> lib/test_bpf.c tests for eBPF constant blinding" caught my eye. Is this >>> something that still needs to be done? If so, is there someone specific that >>> I can reach out to in order to get some guidance on where to start? >> >> Hi! Welcome to the fun. :) >> >> I've added Elena and Daniel to CC, who both worked on the blinding. >> The goal would be to add some kind of test that inserted constants in >> eBPF instructions and then verified they were gone in the resulting >> eBPF JIT kernel code. Until now, it's only been done manually, and >> it'd be nice to have a test that could show if there were regressions >> or if an architecture didn't support the blinding in its JIT. >> >> For some background on the blinding, I wrote a short description of it here: >> https://outflux.net/blog/archives/2016/10/03/security-things-in-linux-v4-7/ >> >> Let me know if that helps get you to a starting point! :) >> >> -Kees >> >> -- >> Kees Cook >> Nexus Security > > >
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.