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

[Levente Kurusa <levex@linux.com>]

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

Hi,

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:
> > Hi,
> > 
> > On Sun, May 11, 2014 at 06:37:47PM +0200, Laurent Pinchart wrote:
> > > On Sunday 11 May 2014 18:29:18 Levente Kurusa wrote:
> ...
> > > > Not sure about how would we create the bugzilla entry? I mean, which
> > > > section, urgency, etc. how would we decide on those solely based on
> > > > the OOPS? Or should we ask the user to fill it out?
> > > 
> > > Filling a complex form on a handheld device can be pretty tedious. A two steps 
> > > procedure that would allow entering long text on a real computer could be an 
> > > interesting option.
> > > 
> > 
> > Makes sense.
> > 
> > What about only asking for an email address and then sending them
> > an automated message with a link where they can continue to add more
> > information to the report? (i.e. fill out the bugzilla)
> 
> Agree.
> 
> > 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.

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?

Thanks,
    Levente Kurusa

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]