diff for duplicates of <577CB5B7.7040204@huawei.com> diff --git a/a/1.txt b/N1/1.txt index ab61867..9bd0114 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,6 @@ HI, -When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to c - heck whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it +When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to check whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it found several wrapper issues in glibc. I will first explain the different with existing fuzz tools and paste my propsosal in the end. Trinity is developed in a long time. It could randomize the parameter of syscall and run individual syscall standalone or parallel. When I do the long time parallel test(not for ILP32), it could report some bug, e.g. hang, panic. It is useful but it is indeed hard to debug because it usually fail after a long time running. I do not know what does it exactly do. diff --git a/a/content_digest b/N1/content_digest index 591b6b2..f3103bf 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -28,8 +28,7 @@ "b\0" "HI,\n" "\n" - "When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to c\n" - " heck whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it \n" + "When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to check whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it \n" "found several wrapper issues in glibc. I will first explain the different with existing fuzz tools and paste my propsosal in the end.\n" "\n" "Trinity is developed in a long time. It could randomize the parameter of syscall and run individual syscall standalone or parallel. When I do the long time parallel test(not for ILP32), it could report some bug, e.g. hang, panic. It is useful but it is indeed hard to debug because it usually fail after a long time running. I do not know what does it exactly do.\n" @@ -107,4 +106,4 @@ "[5] https://github.com/bjzhang/trinity/tree/syscall_unittest\n" [6] https://github.com/bjzhang/abi-dumper/tree/json_output -ded30b0c0f46171e2ed86c5be023b9372b8748e6e7a78b0b04ef6056b7baaf26 +20bfa859075990b8fec405b45f85259cefe2ccc39dfd38baf38410bf3199cdc4
diff --git a/a/1.txt b/N2/1.txt index ab61867..9bd0114 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,7 +1,6 @@ HI, -When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to c - heck whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it +When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to check whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it found several wrapper issues in glibc. I will first explain the different with existing fuzz tools and paste my propsosal in the end. Trinity is developed in a long time. It could randomize the parameter of syscall and run individual syscall standalone or parallel. When I do the long time parallel test(not for ILP32), it could report some bug, e.g. hang, panic. It is useful but it is indeed hard to debug because it usually fail after a long time running. I do not know what does it exactly do. diff --git a/a/content_digest b/N2/content_digest index 591b6b2..8ccb66e 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,35 +1,34 @@ "From\0Zhangjian (Bamvor) <bamvor.zhangjian@huawei.com>\0" "Subject\0[RFD] Efficient unit test and fuzz tools for kernel/libc porting\0" "Date\0Wed, 6 Jul 2016 15:39:35 +0800\0" - "To\0linux-kernel@vger.kernel.org" - linux-arch@vger.kernel.org - libc-alpha@sourceware.org - trinity@vger.kernel.org - syzkaller@googlegroups.com - aponomarenko@rosalab.ru + "To\0<linux-kernel@vger.kernel.org>" + <linux-arch@vger.kernel.org> + <libc-alpha@sourceware.org> + <trinity@vger.kernel.org> + <syzkaller@googlegroups.com> + <aponomarenko@rosalab.ru> Jess Hertz <jesse.hertz@nccgroup.trust> " Tim Newsham <tim.newsham@nccgroup.trust>\0" - "Cc\0arnd@arndb.dea" - catalin.marinas@arm.com - broonie@kernel.org - joseph@codesourcery.com - maxim.kuvyrkov@linaro.org - ynorov@caviumnetworks.com - pinskia@gmail.com - schwab@suse.de - agraf@suse.de - marcus.shawcroft@arm.com - dingtianhong@huawei.com - guohanjun@huawei.com - cuibixuan@huawei.com - lijinyue@huawei.com - " lizefan@huawei.com\0" + "Cc\0<arnd@arndb.dea>" + <catalin.marinas@arm.com> + <broonie@kernel.org> + <joseph@codesourcery.com> + <maxim.kuvyrkov@linaro.org> + <ynorov@caviumnetworks.com> + <pinskia@gmail.com> + <schwab@suse.de> + <agraf@suse.de> + <marcus.shawcroft@arm.com> + <dingtianhong@huawei.com> + <guohanjun@huawei.com> + <cuibixuan@huawei.com> + <lijinyue@huawei.com> + " <lizefan@huawei.com>\0" "\00:1\0" "b\0" "HI,\n" "\n" - "When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to c\n" - " heck whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it \n" + "When I working on the ILP32 ABI for ARMv8 in last two years, I has encountered lots of syscall issues such as wrong number of arguments, different data type in binary interface. I realized that the correctness of argument passing between the C library and core kernel code is a common problem when bringing up new architecture or ABI to kernel and libc. Existing fuzz testing tools such as trinity[1], syzkaller[2] and triforce[3] only generate random or boundary values for syscall parameters and then inject them into kernel, but those tools won't validate if the results of those syscalls are correct or not. Thus they can not act as an unit test for ILP32. In this year, considering the abi of ILP32 is changes during discussion, I am thinking if I could use some sort of automatically tools to check whether the wrapper is correct or not. After learn and compare some fuzz tools, I feel that there is no such fuzz tools could help me. So, I wrote a new fuzz tools base on the trinity and it \n" "found several wrapper issues in glibc. I will first explain the different with existing fuzz tools and paste my propsosal in the end.\n" "\n" "Trinity is developed in a long time. It could randomize the parameter of syscall and run individual syscall standalone or parallel. When I do the long time parallel test(not for ILP32), it could report some bug, e.g. hang, panic. It is useful but it is indeed hard to debug because it usually fail after a long time running. I do not know what does it exactly do.\n" @@ -107,4 +106,4 @@ "[5] https://github.com/bjzhang/trinity/tree/syscall_unittest\n" [6] https://github.com/bjzhang/abi-dumper/tree/json_output -ded30b0c0f46171e2ed86c5be023b9372b8748e6e7a78b0b04ef6056b7baaf26 +f35cf9f1969c95932f360a45d037d17f7a44678f7bcdef90694b3b06f150bdaf
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.