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]

Message-ID: <20171009140051.lk3377lf7b3abcah@sasha-lappy>
Date:   Mon, 9 Oct 2017 14:00:53 +0000
From:   "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Will Deacon <will.deacon@....com>, Mark Brown <broonie@...nel.org>,
        "Mark Rutland" <mark.rutland@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        "Laura Abbott" <labbott@...hat.com>
Subject: Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Mon, Oct 09, 2017 at 01:42:26PM +0200, Greg Kroah-Hartman wrote:
>On Mon, Oct 09, 2017 at 11:06:53AM +0100, Will Deacon wrote:
>> On Mon, Oct 09, 2017 at 10:14:50AM +0100, Mark Brown wrote:
>> > On Sat, Oct 07, 2017 at 03:10:06AM +0000, 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.
>> >
>> > If you're sending patches that were identified by a bot rather than a
>> > domain expert it'd be really good to flag these *very* clearly (eg, by
>> > sending the submissions with a different sender address) as they'll need
>> > much more careful review than things that came in via a domain expert.
>> > When they come from someone who's a stable maintainer as part of a big
>> > batch of patches that doesn't look like a new submission from a not that
>> > trusted source.
>>
>> Taking this a bit further, I think ideally the subject would identify
>> whether or not the patch was selected by a bot, and it shouldn't get
>> backported to stable unless either the author or maintainer acks the patch,
>> or there is a tested-by from somebody reporting that it fixes a bug on
>> that stable tree that has actually been seen without it.
>>
>> On the flip side, it means that the default response (silence) stops the
>> patches getting into stable, which isn't ideal for Greg. Thoughts?
>
>Yeah, default "do not take" isn't going to work, let's try just adding
>another "this was picked because..." type line instead.
>
>I know Sasha goes over these, and so do I, much more carefully than the
>"normal" stable patches.  But things slip in, like this one, at times.

I don't have an objection to adding another "pick by bot" line.

Note, also, that they go through a much longer review cycle: I send
out reviews and wait for comments for atleast a week, at which point
I send Greg a pull request (which he usually grabs after another week)
at which point a bunch more mails are sent out to the author/mailing
lists notifying that this patch was added.

In this case, for example, this patch had a "review cycle" of 18 days
where 4 different emails regarding this patch were sent out as it was
making it's way through review and queues, so we already try to be
as "loud" as we can with it.

At this point, we have almost 400 commits that were selected this way
and are now in the 4.9 LTS tree, and the recorded error rate so far
is slightly higher than 2%, which is in line with the average error
chance of a "regular" commit going into stable.

-- 

Thanks,
Sasha