Attach eBPF bytecode to SOCK_STREAM socket












0















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;
}









share|improve this question





























    0















    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;
    }









    share|improve this question



























      0












      0








      0








      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;
      }









      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 20 '18 at 0:37







      Alexander Gryanko

















      asked Nov 19 '18 at 21:39









      Alexander GryankoAlexander Gryanko

      4221918




      4221918
























          1 Answer
          1






          active

          oldest

          votes


















          -1














          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






          share|improve this answer
























          • 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 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













          • @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











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          -1














          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






          share|improve this answer
























          • 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 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













          • @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
















          -1














          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






          share|improve this answer
























          • 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 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













          • @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














          -1












          -1








          -1







          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






          share|improve this answer













          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







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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 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













          • @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











          • 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











          • @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


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          MongoDB - Not Authorized To Execute Command

          in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith

          Npm cannot find a required file even through it is in the searched directory