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 19:31:00 +0200 (CEST)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>
cc:     Laura Abbott <labbott@...hat.com>,
        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>
Subject: Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()



On Tue, 10 Oct 2017, Levin, Alexander (Sasha Levin) wrote:

> (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 :)

That's a good summary of the current status.  Thanks!

julia