[Ksummit-discuss] [TECH TOPIC] QR encoded oops for the kernel
Jason Cooper
jason at lakedaemon.net
Mon May 12 17:24:49 UTC 2014
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.
More information about the Ksummit-discuss
mailing list