From: Daniel Borkmann <daniel@iogearbox.net>
To: Kees Cook <keescook@chromium.org>,
Sandra Escandor-O'Keefe <rvonflugel@gmail.com>
Cc: "Reshetova, Elena" <elena.reshetova@intel.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
alexei.starovoitov@gmail.com
Subject: Re: [kernel-hardening] Working on lib/test_bpf.c tests for eBPF constant blinding
Date: Fri, 16 Dec 2016 21:11:01 +0100 [thread overview]
Message-ID: <58544A55.7080301@iogearbox.net> (raw)
In-Reply-To: <CAGXu5jJ=SzfLsLm=CS8FniYqRAntj+_1MH4g1=isHQ1t3rcb4Q@mail.gmail.com>
On 12/16/2016 09:02 PM, Kees Cook wrote:
> On Fri, Dec 16, 2016 at 11:47 AM, Sandra Escandor-O'Keefe
> <rvonflugel@gmail.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@chromium.org
>> Sent: December 16, 2016 3:28 PM
>> To: rvonflugel@gmail.com
>> Cc: kernel-hardening@lists.openwall.com; elena.reshetova@intel.com; daniel@iogearbox.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@gmail.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
>
>
>
prev parent reply other threads:[~2016-12-16 20:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-16 17:13 [kernel-hardening] Working on lib/test_bpf.c tests for eBPF constant blinding Sandra Escandor-O'Keefe
2016-12-16 18:58 ` Kees Cook
2016-12-16 19:47 ` Sandra Escandor-O'Keefe
2016-12-16 20:02 ` Kees Cook
2016-12-16 20:11 ` Daniel Borkmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58544A55.7080301@iogearbox.net \
--to=daniel@iogearbox.net \
--cc=alexei.starovoitov@gmail.com \
--cc=elena.reshetova@intel.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=rvonflugel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.