Attach eBPF bytecode to SOCK_STREAM socket
I'm using https://elixir.bootlin.com/linux/v4.9.137/source/samples/bpf/sockex3_kern.c this example, but instead of the RAW socket, I'm using ordinary AF_INET6/SOCK_STREAM and BPF_PROG_TYPE_SOCKET_FILTER.
I can't understand why load_half is used to read proto. First 32 bits is the length field:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
__u32 proto = load_half(skb, 12);
char fmt = "PROTO %xn";
bpf_trace_printk(fmt, sizeof(fmt), proto);
}
Or if I try to do this:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
u64 proto = load_half(skb, 12);
char fmt = "PROTO %x %un";
void *data = (void *)(long)skb->data;
struct ethhdr *eth = data;
void *data_end = (void *)(long)skb->data_end;
...
}
I got "invalid bpf_context access off=80 size=4" error. As I understand I should read all the data from "data" field here.
So, maybe someone can tell me where the first 34 bytes(eth + ip header) was trimmed for current sk_buff? Somewhere in tcp_v4_rcv?
Is it possible to access IP header fields with SOCK_STREAM socket?
UPD:
Looks like there is no way to directly access data from the filter:
https://elixir.bootlin.com/linux/v4.9.137/source/net/core/filter.c#L2647
switch (off) {
case offsetof(struct __sk_buff, tc_classid):
case offsetof(struct __sk_buff, data):
case offsetof(struct __sk_buff, data_end):
return false;
}
linux sockets kernel bpf
add a comment |
I'm using https://elixir.bootlin.com/linux/v4.9.137/source/samples/bpf/sockex3_kern.c this example, but instead of the RAW socket, I'm using ordinary AF_INET6/SOCK_STREAM and BPF_PROG_TYPE_SOCKET_FILTER.
I can't understand why load_half is used to read proto. First 32 bits is the length field:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
__u32 proto = load_half(skb, 12);
char fmt = "PROTO %xn";
bpf_trace_printk(fmt, sizeof(fmt), proto);
}
Or if I try to do this:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
u64 proto = load_half(skb, 12);
char fmt = "PROTO %x %un";
void *data = (void *)(long)skb->data;
struct ethhdr *eth = data;
void *data_end = (void *)(long)skb->data_end;
...
}
I got "invalid bpf_context access off=80 size=4" error. As I understand I should read all the data from "data" field here.
So, maybe someone can tell me where the first 34 bytes(eth + ip header) was trimmed for current sk_buff? Somewhere in tcp_v4_rcv?
Is it possible to access IP header fields with SOCK_STREAM socket?
UPD:
Looks like there is no way to directly access data from the filter:
https://elixir.bootlin.com/linux/v4.9.137/source/net/core/filter.c#L2647
switch (off) {
case offsetof(struct __sk_buff, tc_classid):
case offsetof(struct __sk_buff, data):
case offsetof(struct __sk_buff, data_end):
return false;
}
linux sockets kernel bpf
add a comment |
I'm using https://elixir.bootlin.com/linux/v4.9.137/source/samples/bpf/sockex3_kern.c this example, but instead of the RAW socket, I'm using ordinary AF_INET6/SOCK_STREAM and BPF_PROG_TYPE_SOCKET_FILTER.
I can't understand why load_half is used to read proto. First 32 bits is the length field:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
__u32 proto = load_half(skb, 12);
char fmt = "PROTO %xn";
bpf_trace_printk(fmt, sizeof(fmt), proto);
}
Or if I try to do this:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
u64 proto = load_half(skb, 12);
char fmt = "PROTO %x %un";
void *data = (void *)(long)skb->data;
struct ethhdr *eth = data;
void *data_end = (void *)(long)skb->data_end;
...
}
I got "invalid bpf_context access off=80 size=4" error. As I understand I should read all the data from "data" field here.
So, maybe someone can tell me where the first 34 bytes(eth + ip header) was trimmed for current sk_buff? Somewhere in tcp_v4_rcv?
Is it possible to access IP header fields with SOCK_STREAM socket?
UPD:
Looks like there is no way to directly access data from the filter:
https://elixir.bootlin.com/linux/v4.9.137/source/net/core/filter.c#L2647
switch (off) {
case offsetof(struct __sk_buff, tc_classid):
case offsetof(struct __sk_buff, data):
case offsetof(struct __sk_buff, data_end):
return false;
}
linux sockets kernel bpf
I'm using https://elixir.bootlin.com/linux/v4.9.137/source/samples/bpf/sockex3_kern.c this example, but instead of the RAW socket, I'm using ordinary AF_INET6/SOCK_STREAM and BPF_PROG_TYPE_SOCKET_FILTER.
I can't understand why load_half is used to read proto. First 32 bits is the length field:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
__u32 proto = load_half(skb, 12);
char fmt = "PROTO %xn";
bpf_trace_printk(fmt, sizeof(fmt), proto);
}
Or if I try to do this:
SEC("socket/0")
int bpf_prog(struct __sk_buff *skb)
{
u64 proto = load_half(skb, 12);
char fmt = "PROTO %x %un";
void *data = (void *)(long)skb->data;
struct ethhdr *eth = data;
void *data_end = (void *)(long)skb->data_end;
...
}
I got "invalid bpf_context access off=80 size=4" error. As I understand I should read all the data from "data" field here.
So, maybe someone can tell me where the first 34 bytes(eth + ip header) was trimmed for current sk_buff? Somewhere in tcp_v4_rcv?
Is it possible to access IP header fields with SOCK_STREAM socket?
UPD:
Looks like there is no way to directly access data from the filter:
https://elixir.bootlin.com/linux/v4.9.137/source/net/core/filter.c#L2647
switch (off) {
case offsetof(struct __sk_buff, tc_classid):
case offsetof(struct __sk_buff, data):
case offsetof(struct __sk_buff, data_end):
return false;
}
linux sockets kernel bpf
linux sockets kernel bpf
edited Nov 20 '18 at 0:37
Alexander Gryanko
asked Nov 19 '18 at 21:39
Alexander GryankoAlexander Gryanko
4221918
4221918
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
According to latest kernel sources, protocol is 16-byte offset, not 12!
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L2305
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in thestruct __sk_buff
(e.g.skb->data
and notskb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.
– Qeole
Nov 19 '18 at 23:31
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53383017%2fattach-ebpf-bytecode-to-sock-stream-socket%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
According to latest kernel sources, protocol is 16-byte offset, not 12!
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L2305
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in thestruct __sk_buff
(e.g.skb->data
and notskb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.
– Qeole
Nov 19 '18 at 23:31
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
|
show 1 more comment
According to latest kernel sources, protocol is 16-byte offset, not 12!
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L2305
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in thestruct __sk_buff
(e.g.skb->data
and notskb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.
– Qeole
Nov 19 '18 at 23:31
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
|
show 1 more comment
According to latest kernel sources, protocol is 16-byte offset, not 12!
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L2305
According to latest kernel sources, protocol is 16-byte offset, not 12!
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L2305
answered Nov 19 '18 at 22:14
JokerJoker
1
1
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in thestruct __sk_buff
(e.g.skb->data
and notskb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.
– Qeole
Nov 19 '18 at 23:31
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
|
show 1 more comment
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in thestruct __sk_buff
(e.g.skb->data
and notskb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.
– Qeole
Nov 19 '18 at 23:31
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Thank you, but I'm using 4.9 kernel version.
– Alexander Gryanko
Nov 19 '18 at 22:17
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
Same stuff in 4.9.137. They say "new fields can only be added to the end of this structure" - hardly they have added a new field in the beginning for 4.19: elixir.bootlin.com/linux/v4.9.137/source/include/uapi/linux/…
– Joker
Nov 19 '18 at 22:21
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in the struct __sk_buff
(e.g. skb->data
and not skb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.– Qeole
Nov 19 '18 at 23:31
load_half()
translates into a "load absolute" kind of instruction that actually takes its offset from the start of packet data, not in the struct __sk_buff
(e.g. skb->data
and not skb
). So offset 12 is the correct one for the ethertype field in that case, after the MAC destination and source addresses.– Qeole
Nov 19 '18 at 23:31
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@Qeole I think you should make your comment into an answer. It answers all of the OP's questions.
– pchaigno
Nov 20 '18 at 10:23
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
@pchaigno It's helpful, but only for RAW sockets. I can't find where eth/ip levels were trimmed.
– Alexander Gryanko
Nov 20 '18 at 13:20
|
show 1 more comment
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53383017%2fattach-ebpf-bytecode-to-sock-stream-socket%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown