[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+1xoqf67X54baE7VpXrB_oTqj5JP3gZaq0VRGa8bhQaR7v2Yg@mail.gmail.com>
Date: Wed, 3 Oct 2018 18:01:45 -0400
From: Sasha Levin <levinsasha928@...il.com>
To: Dhaval Giani <dhaval.giani@...il.com>,
Sasha Levin <alexander.levin@...rosoft.com>,
"linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>,
Alice Ferrazzi <alice.ferrazzi@...il.com>,
khilman@...libre.com, Tim Bird <tbird20d@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>, labbott@...hat.com,
Steven Rostedt <rostedt@...dmis.org>,
gustavo.padovan@...labora.co.uk, dan.carpenter@...cle.com,
willy@...radead.org, knut.omang@...cle.com
Cc: Liam.Howlett@...cle.com
Subject: Re: [Announce] LPC 2018: Testing and Fuzzing Microconference
On Wed, Oct 3, 2018 at 3:16 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
>
> * Sasha Levin <levinsasha928@...il.com> [181002 17:03]:
> > On Tue, Oct 2, 2018 at 4:44 PM Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> > >
> > > * Dhaval Giani <dhaval.giani@...il.com> [180919 13:15]:
> > > > Hi folks,
> > > >
> > > > Sasha and I are pleased to announce the Testing and Fuzzing track at
> > > > LPC [ 1 ]. We are planning to continue the discussions from last
> > > > year's microconference [2]. Many discussions from the Automated
> > > > Testing Summit [3] will also continue, and a final agenda will come up
> > > > only soon after that.
> > > >
> > > > Suggested Topics
> > > >
> > > > - Syzbot/syzkaller
> > > > - ATS
> > > > - Distro/stable testing
> > > > - kernelci
> > > > - kernelci auto bisection
> > > > - Unit testing framework
> > > >
> > > > We look forward to other interesting topics for this microconference
> > > > as a reply to this email.
> > > >
> > > > Thanks!
> > > > Dhaval and Sasha
> > > >
> > > > [1] https://blog.linuxplumbersconf.org/2018/testing-and-fuzzing-mc/
> > > > [2] https://lwn.net/Articles/735034/
> > > > [3] https://elinux.org/Automated_Testing_Summit
> > >
> > >
> > > Hello,
> > >
> > > I have a new way to analyze binaries to detect specific calls without
> > > the need for source. I would like to discuss Machine Code Trace
> > > (MCTrace) at the Testing and Fuzzing LPC track. MCTrace intercepts the
> > > application prior to execution and does not rely on a specific user
> > > input. It then decodes the machine instructions to follow all control
> > > flows to their natural conclusions. This includes control flows that go
> > > beyond the boundaries of the static executable code into shared
> > > libraries. This new technique avoids false positives which could be
> > > produced by static analysis and includes paths that could be missed by
> > > dynamic tracing. This type of analysis could be useful in both testing
> > > and fuzzing by providing a call graph to a given function.
> > >
> > > MCTrace was initially designed to help generate the seccomp() filter
> > > list, which is a whitelist/blacklist of system calls for a specific
> > > application. Seccomp filters easily become outdated when the application
> > > or shared library is updated. This can cause failures or security
> > > issues [ 1 ]. Other potential uses including examining binary blobs,
> > > vulnerability analysis, and debugging.
> >
> > Hi Liam,
> >
> > Is MCTrace available anywhere?
>
> Hello Sasha,
>
> I missed this email as I was not CC'ed.
Sorry about that, I must have messed something up.
> MCTrace is currently a proof-of-concept and the source is not available.
What is the reason behind it not being available?
> There are a number of instructions that need additional work, but I have
> some test applications that can be analyzed. I'd like to explain the
> concept, why it is useful, and debate other potential uses.
I have 2 concerns here:
1. This is an interesting new field to explore but since no one is
familiar with how this works, nor anyone can actually play and tinker
with it, I suspect that the ~30 min you'll have to discuss it will be
spent on describing how it works and answering basic questions. This
seems like a better fit for a refereed track session rather than MC.
2. In general, I don't think we can or should discuss a closed source
project. Sure, we can discuss the concept itself, but in that case I
don't see how it will benefit the community.
--
Thanks,
Sasha
Powered by blists - more mailing lists