On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog: "At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets."
To make attacker job harder introduce BPF_JIT_ALWAYS_ON config option that removes interpreter from the kernel in favor of JIT-only mode. So far eBPF JIT is supported by: x64, arm64, arm32, sparc64, s390, powerpc64, mips64
The start of JITed program is randomized and code page is marked as read-only. In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
v2->v3:
- move __bpf_prog_ret0 under ifdef (Daniel)
v1->v2:
- fix init order, test_bpf and cBPF (Daniel's feedback)
- fix offloaded bpf (Jakub's feedback)
- add 'return 0' dummy in case something can invoke prog->bpf_func
- retarget bpf tree. For bpf-next the patch would need one extra hunk.
It will be sent when the trees are merged back to net-next
Considered doing: int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; but it seems better to land the patch as-is and in bpf-next remove bpf_jit_enable global variable from all JITs, consolidate in one place and remove this jit_init() function.
Signed-off-by: Alexei Starovoitov ast@kernel.org
Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog: "At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets."
To make attacker job harder introduce BPF_JIT_ALWAYS_ON config option that removes interpreter from the kernel in favor of JIT-only mode. So far eBPF JIT is supported by: x64, arm64, arm32, sparc64, s390, powerpc64, mips64
The start of JITed program is randomized and code page is marked as read-only. In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
v2->v3:
- move __bpf_prog_ret0 under ifdef (Daniel)
v1->v2:
- fix init order, test_bpf and cBPF (Daniel's feedback)
- fix offloaded bpf (Jakub's feedback)
- add 'return 0' dummy in case something can invoke prog->bpf_func
- retarget bpf tree. For bpf-next the patch would need one extra hunk.
It will be sent when the trees are merged back to net-next
Considered doing: int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; but it seems better to land the patch as-is and in bpf-next remove bpf_jit_enable global variable from all JITs, consolidate in one place and remove this jit_init() function.
Signed-off-by: Alexei Starovoitov ast@kernel.org
Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
Any word on these? Worse case, a simple list of git commit ids to backport is all I need.
thanks,
greg k-h
On 01/28/2018 03:45 PM, Greg KH wrote:
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog: "At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets."
To make attacker job harder introduce BPF_JIT_ALWAYS_ON config option that removes interpreter from the kernel in favor of JIT-only mode. So far eBPF JIT is supported by: x64, arm64, arm32, sparc64, s390, powerpc64, mips64
The start of JITed program is randomized and code page is marked as read-only. In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
v2->v3:
- move __bpf_prog_ret0 under ifdef (Daniel)
v1->v2:
- fix init order, test_bpf and cBPF (Daniel's feedback)
- fix offloaded bpf (Jakub's feedback)
- add 'return 0' dummy in case something can invoke prog->bpf_func
- retarget bpf tree. For bpf-next the patch would need one extra hunk.
It will be sent when the trees are merged back to net-next
Considered doing: int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; but it seems better to land the patch as-is and in bpf-next remove bpf_jit_enable global variable from all JITs, consolidate in one place and remove this jit_init() function.
Signed-off-by: Alexei Starovoitov ast@kernel.org
Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
Any word on these? Worse case, a simple list of git commit ids to backport is all I need.
Sorry for the delay! There are various conflicts all over the place, so I had to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9 out hopefully tonight as well, and the rest for 4.4 on Mon.
On Mon, Jan 29, 2018 at 12:40:47AM +0100, Daniel Borkmann wrote:
On 01/28/2018 03:45 PM, Greg KH wrote:
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
The BPF interpreter has been used as part of the spectre 2 attack CVE-2017-5715.
A quote from goolge project zero blog: "At this point, it would normally be necessary to locate gadgets in the host kernel code that can be used to actually leak data by reading from an attacker-controlled location, shifting and masking the result appropriately and then using the result of that as offset to an attacker-controlled address for a load. But piecing gadgets together and figuring out which ones work in a speculation context seems annoying. So instead, we decided to use the eBPF interpreter, which is built into the host kernel - while there is no legitimate way to invoke it from inside a VM, the presence of the code in the host kernel's text section is sufficient to make it usable for the attack, just like with ordinary ROP gadgets."
To make attacker job harder introduce BPF_JIT_ALWAYS_ON config option that removes interpreter from the kernel in favor of JIT-only mode. So far eBPF JIT is supported by: x64, arm64, arm32, sparc64, s390, powerpc64, mips64
The start of JITed program is randomized and code page is marked as read-only. In addition "constant blinding" can be turned on with net.core.bpf_jit_harden
v2->v3:
- move __bpf_prog_ret0 under ifdef (Daniel)
v1->v2:
- fix init order, test_bpf and cBPF (Daniel's feedback)
- fix offloaded bpf (Jakub's feedback)
- add 'return 0' dummy in case something can invoke prog->bpf_func
- retarget bpf tree. For bpf-next the patch would need one extra hunk.
It will be sent when the trees are merged back to net-next
Considered doing: int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT; but it seems better to land the patch as-is and in bpf-next remove bpf_jit_enable global variable from all JITs, consolidate in one place and remove this jit_init() function.
Signed-off-by: Alexei Starovoitov ast@kernel.org
Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
Any word on these? Worse case, a simple list of git commit ids to backport is all I need.
Sorry for the delay! There are various conflicts all over the place, so I had to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9 out hopefully tonight as well, and the rest for 4.4 on Mon.
Not a problem at all, wanted to make sure I didn't miss them having be posted somewhere I missed :)
If you need/want help for the 4.4 stuff, just let me know, and I'll be glad to work on it.
thanks,
greg k-h
On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
On 01/28/2018 03:45 PM, Greg KH wrote:
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
[...]
Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
Any word on these? Worse case, a simple list of git commit ids to backport is all I need.
Sorry for the delay! There are various conflicts all over the place, so I had to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9 out hopefully tonight as well, and the rest for 4.4 on Mon.
While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even boot on my machine. While I can shortly see the kernel log, my screen turns black shortly thereafter and nothing reacts anymore. No such problems with 4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?
Thanks, Daniel
On Mon, Jan 29, 2018 at 04:36:35PM +0100, Daniel Borkmann wrote:
On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
On 01/28/2018 03:45 PM, Greg KH wrote:
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
[...]
Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
Any word on these? Worse case, a simple list of git commit ids to backport is all I need.
Sorry for the delay! There are various conflicts all over the place, so I had to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9 out hopefully tonight as well, and the rest for 4.4 on Mon.
While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even boot on my machine. While I can shortly see the kernel log, my screen turns black shortly thereafter and nothing reacts anymore. No such problems with 4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?
Not that I know of, sorry. Odd graphics issue perhaps?
If you have some test programs I can run, I can look into doing the backports, I still have a laptop around here that runs 4.4 :)
There's always a virtual machine as well, have you tried that?
thanks,
greg k-h
On 01/29/2018 06:36 PM, Greg KH wrote:
On Mon, Jan 29, 2018 at 04:36:35PM +0100, Daniel Borkmann wrote:
On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
On 01/28/2018 03:45 PM, Greg KH wrote:
On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
On 01/24/2018 11:07 AM, David Woodhouse wrote:
On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote: > On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
[...]
> Applied to bpf tree, thanks Alexei!
For stable too?
Yes, this will go into stable as well; batch of backports will come Thurs/Fri.
Any word on these? Worse case, a simple list of git commit ids to backport is all I need.
Sorry for the delay! There are various conflicts all over the place, so I had to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9 out hopefully tonight as well, and the rest for 4.4 on Mon.
While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even boot on my machine. While I can shortly see the kernel log, my screen turns black shortly thereafter and nothing reacts anymore. No such problems with 4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?
Not that I know of, sorry. Odd graphics issue perhaps?
If you have some test programs I can run, I can look into doing the backports, I still have a laptop around here that runs 4.4 :)
There's always a virtual machine as well, have you tried that?
I've switched to an arm64 node now, that's working fine with 4.4, so patches will come later tonight.
Thanks, Daniel
linux-stable-mirror@lists.linaro.org
-
Daniel Borkmann -
Greg KH