From anolasc13 at gmail.com Mon Aug 1 15:54:48 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Mon, 1 Aug 2022 23:54:48 +0800 Subject: Su Hsueyu's GSoC status report - #3 of 12 Message-ID: Accomplishments: - read tests/bpf.c - complete the map retrieving demo by retrieving map key and value type information - run the bpf unit test - writing bpf-obj_get_info_by_fd-map.c Priorities: - continue writing the map unit test - try to implement map retrieving in strace From anolasc13 at gmail.com Mon Aug 8 14:59:13 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Mon, 8 Aug 2022 22:59:13 +0800 Subject: Su Hsueyu's GSoC status report - #4 of 12 Message-ID: Accomplishments: - Write auxiliary functions for retrieving type information of ebpf maps Priorities: - Implement map type information retrieving in strace - Continue writing the map unit test Took a lot of effort to write the unit test, yet it is still hard to achieve. I think it would be wiser and more efficient to move my focus to implementing the ebpf map type information retrieval. From ldv at altlinux.org Fri Aug 12 19:46:24 2022 From: ldv at altlinux.org (Dmitry V. Levin) Date: Fri, 12 Aug 2022 22:46:24 +0300 Subject: strace 5.19 released Message-ID: <20220812194624.GA7562@altlinux.org> Starting with version 4.13, strace follows the schedule of linux kernel and new versions of strace are released along with new versions of linux kernel, so strace 5.19 is tagged and uploaded. strace 5.19 would not be as good as it is without significant assistance by Eugene Syromyatnikov. $ git tag -v v5.19 2> /dev/null | sed -n '/^$/,$p' Noteworthy changes in strace 5.19 (2022-08-12) ============================================== * Changes in behaviour * The "(deleted)" marker for unlinked paths of file descriptors is now printed outside angle brackets; the matching of unlinked paths of file descriptors no longer includes the " (deleted)" part into consideration. * Improvements * Implemented printing of Unix socket sun_path field's SELinux context. * Implemented decoding of SO_TXREHASH socket option. * Implemented decoding of IFLA_TSO_MAX_SIZE, IFLA_TSO_MAX_SEGS, NDA_FDB_EXT_ATTRS, NDA_FLAGS_EXT, NDA_NDM_FLAGS_MASK, and NDA_NDM_STATE_MASK netlink attributes. * Improved decoding of INET_DIAG_LOCALS, INET_DIAG_MD5SIG, INET_DIAG_PEERS, INET_DIAG_PROTOCOL, INET_DIAG_REQ_PROTOCOL, INET_DIAG_SHUTDOWN, INET_DIAG_SK_BPF_STORAGES, INET_DIAG_SOCKOPT, and INET_DIAG_ULP_INFO NETLINK_SOCK_DIAG netlink attributes. * Enhanced decoding of arch_prctl and prctl syscalls. * Enhanced siginfo_t decoding. * Updated decoding of struct rtnl_link_stats64. * Updated lists of DEVCONF_*, FAN_MARK_*, GPIO_V2_LINE_FLAG_*, IORING_*, KEXEC_*, LANDLOCK_*, NET_IPV4_CONF_*, NLM_F_*, NT_*, PR_*, SECCOMP_*, UFFD_FEATURE_*, V4L2_CID_*, and V4L2_PIX_FMT_* constants. * Updated lists of ioctl commands from Linux 5.19. * Bug fixes Contributors ============ This release was made possible by the contributions of many people. The maintainers are grateful to everyone who has contributed changes or bug reports. These include: * Alexey Gladkov * Dmitry V. Levin * Eugene Syromyatnikov * Gleb Fotengauer-Malinovskiy * Joubin Jabbari * Lenka ?pa?kov? * Renaud M?trich * Sergei Trofimovich * V?clav Kadl??k Please refer to the CREDITS file for the full list of strace contributors. -- ldv -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From anolasc13 at gmail.com Mon Aug 15 14:22:04 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Mon, 15 Aug 2022 22:22:04 +0800 Subject: Su Hsueyu's GSoC status report - #5 of 12 Message-ID: Accomplishments: - Write auxiliary functions for retrieving type information of ebpf maps - Implement map type information retrieving in strace Priorities: - Continue writing the map unit test - Debug Hello, I am debugging my code writing in strace. I spend a lot of time in building. I was wondering if you could give me some advice on how to speed up debugging. From anolasc13 at gmail.com Tue Aug 16 16:11:01 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Wed, 17 Aug 2022 00:11:01 +0800 Subject: GSoC [PATCH] add btf_attr for retrieving map btf information' Message-ID: <20220816161101.1259-1-22795996+ANOLASC@users.noreply.github.com> From: SuHsueyu Try to add some structs that used in retriving map btf information --- src/btf_attr.h | 101 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 src/btf_attr.h diff --git a/src/btf_attr.h b/src/btf_attr.h new file mode 100644 index 000000000..7b98ed452 --- /dev/null +++ b/src/btf_attr.h @@ -0,0 +1,101 @@ +#ifndef STRACE_BTF_ATTR_H +#define STRACE_BTF_ATTR_H + +typedef size_t(*hashmap_hash_fn)(const void* key, void* ctx); +typedef bool (*hashmap_equal_fn)(const void* key1, const void* key2, void* ctx); + +struct hashmap_entry { + const void* key; + void* value; + struct hashmap_entry* next; +}; + +struct hashmap { + hashmap_hash_fn hash_fn; + hashmap_equal_fn equal_fn; + void* ctx; + + struct hashmap_entry** buckets; + size_t cap; + size_t cap_bits; + size_t sz; +}; + +struct btf_type { + __u32 name_off; + __u32 info; + union { + __u32 size; + __u32 type; + }; +}; + +enum BTF_KIND { + BTF_KIND_UNKN = 0, /* Unknown */ + BTF_KIND_INT = 1, /* Integer */ + BTF_KIND_PTR = 2, /* Pointer */ + BTF_KIND_ARRAY = 3, /* Array */ + BTF_KIND_STRUCT = 4, /* Struct */ + BTF_KIND_UNION = 5, /* Union */ + BTF_KIND_ENUM = 6, /* Enumeration up to 32-bit values */ + BTF_KIND_FWD = 7, /* Forward */ + BTF_KIND_TYPEDEF = 8, /* Typedef */ + BTF_KIND_VOLATILE = 9, /* Volatile */ + BTF_KIND_CONST = 10, /* Const */ + BTF_KIND_RESTRICT = 11, /* Restrict */ + BTF_KIND_FUNC = 12, /* Function */ + BTF_KIND_FUNC_PROTO = 13, /* Function Proto */ + BTF_KIND_VAR = 14, /* Variable */ + BTF_KIND_DATASEC = 15, /* Section */ + BTF_KIND_FLOAT = 16, /* Floating point */ + BTF_KIND_DECL_TAG = 17, /* Decl Tag */ + BTF_KIND_TYPE_TAG = 18, /* Type Tag */ + BTF_KIND_ENUM64 = 19, /* Enumeration up to 64-bit values */ + + NR_BTF_KINDS, + BTF_KIND_MAX = NR_BTF_KINDS - 1, +}; + +struct strset { + void* strs_data; + size_t strs_data_len; + size_t strs_data_cap; + size_t strs_data_max_len; + struct hashmap* strs_hash; +}; + +struct btf_header { + __u16 magic; + __u8 version; + __u8 flags; + __u32 hdr_len; + + /* All offsets are in bytes relative to the end of this header */ + __u32 type_off; /* offset of type section */ + __u32 type_len; /* length of type section */ + __u32 str_off; /* offset of string section */ + __u32 str_len; /* length of string section */ +}; + +struct btf { + void* raw_data; + void* raw_data_swapped; + __u32 raw_size; + bool swapped_endian; + struct btf_header* hdr; + void* types_data; + size_t types_data_cap; + __u32* type_offs; + size_t type_offs_cap; + __u32 nr_types; + struct btf* base_btf; + int start_id; + int start_str_off; + void* strs_data; + struct strset* strs_set; + bool strs_deduped; + int fd; + int ptr_sz; +}; + +#endif /* !STRACE_BTF_ATTR_H */ \ No newline at end of file -- 2.29.2.windows.3 From ldv at altlinux.org Mon Aug 22 13:53:57 2022 From: ldv at altlinux.org (Dmitry V. Levin) Date: Mon, 22 Aug 2022 16:53:57 +0300 Subject: GSoC [PATCH] add btf_attr for retrieving map btf information' In-Reply-To: <20220816161101.1259-1-22795996+ANOLASC@users.noreply.github.com> References: <20220816161101.1259-1-22795996+ANOLASC@users.noreply.github.com> Message-ID: <20220822135357.GB28171@altlinux.org> Hi, On Wed, Aug 17, 2022 at 12:11:01AM +0800, SuHsueyu wrote: > From: SuHsueyu > > Try to add some structs that used in retriving map btf information > > --- > src/btf_attr.h | 101 +++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 101 insertions(+) > create mode 100644 src/btf_attr.h Submitting a new file would make sense if it would be used somehow. This looks like a first patch in a series of patches, please submit the whole series. -- ldv From anolasc13 at gmail.com Tue Aug 23 14:49:44 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Tue, 23 Aug 2022 22:49:44 +0800 Subject: Su Hsueyu's GSoC status report - #6 of 12 Message-ID: Accomplishments: - Implement BPF_MAP_CREATE retrieving type message for map types. Priorities: - Write unit test - Implement for other sub-commands for bpf map manipulation From anolasc13 at gmail.com Thu Aug 25 16:16:39 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Fri, 26 Aug 2022 00:16:39 +0800 Subject: GSoC: Way to get bpf obj Message-ID: Hello, I'm trying to retrieve info in BPF_MAP_UPDATE_ELEM. And I have noticed that the function fetch_bpf_obj_info is used to fetch info but not using the bpf syscall. I want to ask if it is right choice to retrieve the BPF obj info by using syscall bpf BPF_OBJ_GET_INFO_BY_FD? Or should I just use the function fetch_bpf_obj_info? From evgsyr at gmail.com Mon Aug 29 12:31:21 2022 From: evgsyr at gmail.com (Eugene Syromyatnikov) Date: Mon, 29 Aug 2022 14:31:21 +0200 Subject: GSoC: Way to get bpf obj In-Reply-To: References: Message-ID: On Thu, Aug 25, 2022 at 6:17 PM SuHsueyu wrote: > > Hello, I'm trying to retrieve info in BPF_MAP_UPDATE_ELEM. And I have > noticed that the function fetch_bpf_obj_info is used to fetch info but > not using the bpf syscall. I want to ask if it is right choice to > retrieve the BPF obj info by using syscall bpf BPF_OBJ_GET_INFO_BY_FD? > Or should I just use the function fetch_bpf_obj_info? Well, depends on what objective you want to achieve. fetch_bpf_obj_info() retrieves an existing object info struct from the tracee's memory. If you want to get object information struct that we do not have a hold of a (pertinent at the time of syscall) pointer in tracee's memory, then we need to use the bpf syscall to get such information from the kernel. > -- > Strace-devel mailing list > Strace-devel at lists.strace.io > https://lists.strace.io/mailman/listinfo/strace-devel -- Eugene Syromyatnikov mailto:evgsyr at gmail.com xmpp:esyr at jabber.{ru|org} From anolasc13 at gmail.com Mon Aug 29 16:08:58 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Tue, 30 Aug 2022 00:08:58 +0800 Subject: Su Hsueyu's GSoC status report - #7 of 12 Message-ID: Accomplishments: - Implement BPF_MAP_UPDATE_ELEM retrieving type message for map types. Priorities: - Implement for other sub-commands for bpf map manipulation. Made a little progress this week. I'm struggling to debug the memory problem by using valgrind and gdb. From ldv at altlinux.org Tue Aug 30 19:47:16 2022 From: ldv at altlinux.org (Dmitry V. Levin) Date: Tue, 30 Aug 2022 22:47:16 +0300 Subject: [rfc] new generic ptrace api for setting syscall info In-Reply-To: References: Message-ID: <20220830194716.GA28383@altlinux.org> Hi, On Tue, Nov 02, 2021 at 02:50:58PM +0100, Renzo Davoli wrote: > I am sorry for the delay. Life synch problems. > > at a high level, i like where this is going. i think we should break them up as > > (1) that's how you get things reviewed & accepted faster, > > (2) certain pieces need more help from arches than others, > > (3) they look easy to break up & make logically independent, > > (4) i selfishly care more for some aspects than others :), > > (5) i want to avoid an "all or nothing" type of functionality merge. > Agree, entirely, including (4) for my interests. > > > > the functionality that matters to me with PTRACE_SET_SYSCALL_INFO: > > * set syscall nr (e.g. skip it) > > * change syscall arguments > > * set syscall return value > > * set syscall error value > > imo, without these, PTRACE_SET_SYSCALL_INFO is not super useful, and seems like > > it'd be hard to partially implement any of these. especially as syscall_set_nr > > is the worst performer, and is a bit of the foundation here. a survey of the > > current asm/syscall.h tree: > > * syscall_set_nr > > (1/22) only csky has this atm > > * syscall_set_arguments > > (14/22) missing alpha arc h8300 hexagon m68k mips parisc sh > > * syscall_set_return_value > > (17/22) missing alpha h8300 hexagon m68k sh > PTRACE_GET_SYSCALL_INFO is provided under the flag: CONFIG_HAVE_ARCH_TRACEHOOK i.e.: > arc arm arm64 csky hexagon ia64 mips nds32 nios2 openrisc parisc powerpc riscv s390 sh sparc x86 xtensa > > It is reasonable to design PTRACE_SET_SYSCALL_INFO for the same set of archs. > so: > * syscall_set_nr > (1/18) only csky has this atm > * syscall_set_arguments > (12/18) missing arc hexagon mips parisc sh > * syscall_set_return_value > (16/18) missing hexagon sh > > > > you've also thrown in these: > > * change IP > > * change SP > > i'm guessing you've done that simply to mirror the API? i would argue that > > these are significantly less interesting (i won't say never as i could think > > of a few). > Not entirely. In vuos we set the IP to repeat the system call. > For what concerns the change of SP, I am with you: it is just to preserve the simmetry. > In similar situations, it has happened to me many times that I discover a suitable usage later. > > so what if we start off with a PTRACE_SET_SYSCALL_INFO that does > > not support changing these values. i'm not sure we could get away with using > > a sentinel value here (e.g. require they be set to -1 else we EINVAL), so > > maybe requiring them to be the same as would be OK ? it's reasonable imo to > > assume the tracer first called PTRACE_GET_SYSCALL_INFO before modifying, so > > they'll have easy access to the current values. if they don't match, we will > > return EINVAL. this will allow merging of the API without also implementing > > the corresponding APIs in asm/ptrace.h. > > * instruction_pointer_set > > (11/22) missing alpha arc h8300 hexagon ia64 m68k microblaze nds32 nios2 openrisc xtensa > (12/18) missing arc hexagon ia64 nds32 nios2 xtensa > > * stack_pointer_set > > (4/22) only mips riscv sh x86 > (4/18) only mips riscv sh x86 > > > > i guess we're just ignoring arch entirely. not unreasonable considering > > changing execution architecture state is ... not useful, if even possible > > for many architectures. > Absolutely > > so should we enforce it be 0 and return an EINVAL > > if it isn't ? otherwise it turns into a field we can never use for anything > > else in the set path. afaict, there is no AUDIT_xxx value that is zero atm, > > and never will be since it encodes the ELF machine (EM_*), and EM_NONE==0. > I envision the default usage of PTRACE_SET_SYSCALL_INFO to be: > ptrace(PTRACE_GET_SYSCALL_INFO, tracee_pid, sizeof(info), &info) > /* modify something in info */ > ptrace(PTRACE_SET_SYSCALL_INFO, tracee_pid, sizeof(info), &info) > so I propose to ignore the value of arch, otherwise programmers need to remember to > set the field to zero prior to call PTRACE_SET_SYSCALL_INFO. > > Looking at the future and aiming at the goal to have the entire PTRACE_SET_SYSCALL_INFO > implementend although through some steps, we need to provide a way to inform > the programmers about which features have been implemented (change IP/change SP), so that > those features can be used if present or a workaround applied. > > I propose to check if IP/SP have been modified on archs where change IP/SP > have not implemented yet and return an EINVAL in case. > The same approach could be applied to an attempt to modify arch. > > > > next you have seccomp improvements. these are interesting, but i think > > important to not block PTRACE_SET_SYSCALL_INFO on since seccomp support is > > a bit spotty already across arches. and it seems like it calls for a bit > > of API bikeshedding. while your reuse of the existing INFO ops doesn't > > feel too terrible since there are direct parallels between them, adding a > > new op that only shows up on set feels a little awkward. it'd be nice if > > we could stick to PTRACE_SYSCALL_INFO_SECCOMP somehow. with the fields we > > have now, we have the syscall number, args, and return value. so can't we > > do what you want ? there's no access to setting an error distinct from a > > return value ... but oes seccomp allow that either ? if not, extending > > that limitation from seccomp to ptrace-seccomp doesn't feel bad. > > One of the features we agree to support in the first patch to propose is: > > * set syscall nr (e.g. skip it) > Skip the system call also means to provide a suitable return value/errno > to be returned to the caller. > So in this case we need to encode for PTRACE_SET_SYSCALL_INFO in some way: > * the info that the syscall must be skipped > * rval/is_error. > Either > we provide a specific tag (as I propose) PTRACE_SYSCALL_INFO_SECCOMP_SKIP > and we use the "exit" branch of the union in struct ptrace_syscall_info > to provide rval/errno, > or > we set seccomp.nr to -1 and then we need to "recycle" the fields in the seccomp > branch (nr, args[6], and ret_data). > seccomp.ret_data is not suitable for the syscall return value as it is _u32, on 64 bits archs > one may need to return 64 bit values. Modify the struct ptrace_syscall_info is > out of scope, it would break the compatibility with the PTRACE_GET_SYSCALL current usage. > So we should use two of the args for rval/errno. > > I am quite supportive for my proposal, When a user wants to skip the system call, > they use a specific tag and set the "exit" fields, as it is an exit, not an entry. > There is no syscall to enter if it has to be skipped. > > > in terms of contributing, i think you can see where my interests align, > > and so i'd be happy to chip in for those parts. but for others, i'll > > just wish you the best of luck :). > > I think we have a quite good alignemnt. Luck is always needed anyway. I wonder has there been any progress with these ideas? -- ldv From anolasc13 at gmail.com Wed Aug 31 16:24:22 2022 From: anolasc13 at gmail.com (SuHsueyu) Date: Thu, 1 Sep 2022 00:24:22 +0800 Subject: GSoC Message-ID: Trying to use bpf BPF_OBJ_GET_INFO_BY_FD to retrieve btf_id in syscall decoder BPF_MAP_UPDATE_ELEM and BPF_MAP_LOOKUP_ELEM. But the syscall BPF_OBJ_GET_INFO_BY_FD is failed and return errno 77, which is "File descriptor in bad state". When I run my demo with the same code, it is fine and able to retrieve btf info. Do you have any views or suggestions on this issue?