linux-kernel - Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Oct 2017 17:22:08 +0000
From:   "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>
To:     Laura Abbott <labbott@...hat.com>
CC:     Mark Rutland <mark.rutland@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        "Will Deacon" <will.deacon@....com>,
        "julia.lawall@...6.fr" <julia.lawall@...6.fr>
Subject: Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

(Cc'ed Julia)

On Mon, Oct 09, 2017 at 09:33:01AM -0700, Laura Abbott wrote:
>On 10/06/2017 08:10 PM, Levin, Alexander (Sasha Levin) wrote:
>> We are experimenting with using neural network to aid with patch
>> selection for stable kernel trees. There are quite a few commits that
>> were not marked for stable, but are stable material, and we're trying
>> to get them into their appropriate kernel trees.
>>
>
>Apart from the practical which has been covered, I'd be interested
>in hearing about the details of how this works if you can share
>them.

This work is based on Julia's work
(https://soarsmu.github.io/papers/icse12-patch.pdf) to identify
commits that fix bugs.

Essentially, my approach to this is to extract as much information as
possbile form the commit, including things such as:

 - How many times a certain word appeared in the message
 - Who is the author
 - Code metrics
 - etc

In my case, I end up with about 30,000 of these "inputs", and train a
neural network based on whether a given commit was included in a
stable tree or not.

This approach has a few drawbacks compared to the one Julia
described in her paper:

 - Not every bug fixing commit ends up in stable (some end up in -rc
fixing a bug from the current merge window).
 - Same as above, but for commits we miss and fail to add to stable.
 - Sometimes commits get added to stable even though they don't follow
the rules at all (security fixes are a simple example).

But it does seem to be effective at finding bug fixing commits that
should be in stable.

At this stage we are still trying to figure out what a "bug fixing"
commit really is. For example, an observation we recently made was
that the code metrics actually don't have much weight in determining
whether a commit should be in stable or not.

As we just started, I'm still experimenting with a few approaches, and
I belive Julia is waiting for a new student to take over this, so we
don't have any big insights to share just yet :)

-- 

Thanks,
Sasha