This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting
- From: "Zhangjian (Bamvor)" <bamvor dot zhangjian at huawei dot com>
- To: Dmitry Vyukov <dvyukov at google dot com>
- Cc: syzkaller <syzkaller at googlegroups dot com>, LKML <linux-kernel at vger dot kernel dot org>, <linux-arch at vger dot kernel dot org>, <libc-alpha at sourceware dot org>, <trinity at vger dot kernel dot org>, <aponomarenko at rosalab dot ru>, Jess Hertz <jesse.hertz@nccgroup.trust>, "Tim Newsham" <tim.newsham@nccgroup.trust>, Arnd Bergmann <arnd at arndb dot de>, "Catalin Marinas" <catalin dot marinas at arm dot com>, Mark Brown <broonie at kernel dot org>, <joseph at codesourcery dot com>, <maxim dot kuvyrkov at linaro dot org>, Yury Norov <ynorov at caviumnetworks dot com>, <pinskia at gmail dot com>, <schwab at suse dot de>, <agraf at suse dot de>, <marcus dot shawcroft at arm dot com>, Ding Tianhong <dingtianhong at huawei dot com>, <guohanjun at huawei dot com>, <cuibixuan at huawei dot com>, <lijinyue at huawei dot com>, Zefan Li <lizefan at huawei dot com>
- Date: Wed, 6 Jul 2016 18:38:11 +0800
- Subject: Re: [RFD] Efficient unit test and fuzz tools for kernel/libc porting
- Authentication-results: sourceware.org; auth=none
- References: <577CB5B7.7040204@huawei.com> <CACT4Y+ZvqA-6CQHjjx05bCPqcOXp7O2Gf8+2PeC7U5eXTL+Yrw@mail.gmail.com> <577CC058.9030103@huawei.com> <CACT4Y+a_5G-G1v4Xn-_dLacuVSNnxGorZMjGKKew6pihg_Hk-Q@mail.gmail.com>
Hi, Dmitry
On 2016/7/6 17:09, Dmitry Vyukov wrote:
On Wed, Jul 6, 2016 at 10:24 AM, Zhangjian (Bamvor)
<bamvor.zhangjian@huawei.com> wrote:
Hi, Dmitry
Hi Bamvor,
Nice work!
Coverage should be easy to do with CONFIG_KCOV, but do you need
fuzzing/coverage? It seems that testing a predefined set of special
values for each arg should be enough for your use case. Namely special
values that can detect endianess/truncation/sign extension/etc issues.
Yes. We are trying to cover endianess/truncation/sign extension at this
moment.
For coverage, there are some code path in syscall wrapper in both glibc
and kernel. E.g. overflow check in glibc. I am thinking if coverage
could help on this.
Ah, you mean user-space coverage. You may try AFL in binary
instrumentation mode for this.
Good idea. AFL seems a wonderful tools. I saw some discussion about use AFL
to do kernel fuzz(triforce). If AFL support arm64, I could try it my
aarch64 ILP32 works.
Regards
Bamvor
I think there is also a number of glibc functions that don't directly
map to syscalls. Most notably wrappers around various ioctl's (e.g.
ptsname). Do you test them?
No. Currently, our tools only focus on the syscall function in glibc. In
these syscall level, we could compare the parameter and return value
directly. As you said, there are only several type of issues. It is easy
to handle by tools.
I do not know how to test these complex cases. E.g. the ptsname may call
ioctl, *stat* syscall. Compare the original parameter is meaningless. But
it seems a good type of testcase to show how the user use the syscalls.
Do you have some ideas?
I don't have any ideas for automated testing. One could write a model,
of course....
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html