Re: [Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel

[Jason Cooper <jason@lakedaemon.net>]

On Mon, May 12, 2014 at 06:49:21PM +0200, Levente Kurusa wrote:
> On Mon, May 12, 2014 at 11:53:20AM -0400, Jason Cooper wrote:
> > On Sun, May 11, 2014 at 07:18:24PM +0200, Levente Kurusa wrote:
...
> > > I guess we should also be careful with the bugzilla. We really don't
> > > want propertiary driver crashes added to the bugzilla automatically.
> > 
> > Correct, but the data is still worth recording.
> > 
> > > Nor do we want the same oops added twice, right?
> > 
> > We don't want two bugzilla entries, but we do want to know how many
> > times this event has happened.
> > 
> > > How would we differentiate between the two - essentially the same -
> > > oopses?
> > 
> > Hmm, oops cookie?  hex string of 32/64 bits read off of the entropy
> > pool?  This would give us an accurate number of events even if a user
> > scans multiple times.
> 
> Hmm, I've been wondering about this too. I guess 32 bits are enough to
> differentiate between oopses, and adding this to the QR code is
> relatively easy as well.

I was thinking directly in the oops.  Never underestimate the tenacity
of a user.  You'll get the qr-code scan, _and_ a bug report filed with a
grainy picture.

> What I wonder is how could we get the server back-end to not
> allow the same oopses from bad users.
> 
> Having a link like:
> 
> oops.kernel.org/submit_oops.php?qr=$ENTROPY$BASE64DATA
> 
> would mean that malicious users could edit the $ENTROPY part and
> hence effectively report the same oops twice. Maybe some checksum?
> Or will it be too much for an already damaged kernel?

encoding it in the oops text makes this a lot more difficult.  Plus,
what is the goal of the attacker in this scenario?

thx,

Jason.