diff for duplicates of <577CBAB7.9020507@huawei.com> diff --git a/a/1.txt b/N1/1.txt index 0a5586c..37ee5a1 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,8 +3,7 @@ Fix the wrong email address for Arnd. Sorry for the noise. On 2016/7/6 15:39, Zhangjian (Bamvor) wrote: > 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 - 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 a +> 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 a > nd 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 138639e..97a6053 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -32,8 +32,7 @@ "On 2016/7/6 15:39, Zhangjian (Bamvor) wrote:\n" "> 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\n" - " 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 a\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 a\n" "> nd it 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" @@ -116,4 +115,4 @@ "> the body of a message to majordomo@vger.kernel.org\n" > More majordomo info at http://vger.kernel.org/majordomo-info.html -fc0682d168e0cd962631a75f9b62760e0d1aaac0dc81583d1db7219d6d702ba7 +f53fdba6eb0a0a02c3dda06bbe0bf45f3f8f771cd632ba99e8ccb4ef9caa3332
diff --git a/a/1.txt b/N2/1.txt index 0a5586c..37ee5a1 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -3,8 +3,7 @@ Fix the wrong email address for Arnd. Sorry for the noise. On 2016/7/6 15:39, Zhangjian (Bamvor) wrote: > 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 - 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 a +> 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 a > nd 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 138639e..6161b12 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -4,10 +4,10 @@ "Date\0Wed, 6 Jul 2016 16:00:55 +0800\0" "To\0LKML <linux-kernel@vger.kernel.org>" Linux-Arch <linux-arch@vger.kernel.org> - libc-alpha@sourceware.org - trinity@vger.kernel.org - syzkaller@googlegroups.com - aponomarenko@rosalab.ru + <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 Bergmann <arnd@arndb.de>" @@ -19,11 +19,11 @@ Andrew Pinski <pinskia@gmail.com> Andreas Schwab <schwab@suse.de> Alexander Graf <agraf@suse.de> - marcus.shawcroft@arm.com + <marcus.shawcroft@arm.com> Ding Tianhong <dingtianhong@huawei.com> Hanjun Guo <guohanjun@huawei.com> - cuibixuan@huawei.com - lijinyue@huawei.com + <cuibixuan@huawei.com> + <lijinyue@huawei.com> " Zefan Li <lizefan@huawei.com>\0" "\00:1\0" "b\0" @@ -32,8 +32,7 @@ "On 2016/7/6 15:39, Zhangjian (Bamvor) wrote:\n" "> 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\n" - " 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 a\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 a\n" "> nd it 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" @@ -116,4 +115,4 @@ "> the body of a message to majordomo@vger.kernel.org\n" > More majordomo info at http://vger.kernel.org/majordomo-info.html -fc0682d168e0cd962631a75f9b62760e0d1aaac0dc81583d1db7219d6d702ba7 +0bce4c5da6a2d1447f98ddc187a151308559de172db3d65c326d9119a7e6f657
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.