ubuntu-bugcontrol team mailing list archive

["Christopher M. Penalver" <christopher.m.penalver@xxxxxxxxx>]

Dear fellow Ubuntu Bug Control members:

I would like to propose adding additional tags to
https://wiki.ubuntu.com/Bugs/Tags in the "Hardware Specific" section
in an effort to provide additional, and vital data points for original
reporters, triagers, and developers, up and downstream.

Specifically, this would be one set of the following, from the
following two sets of choices:

Set A
Tag: latest-bios-VERSION
Use case: The latest BIOS version was confirmed to be installed on the
computer of the original reporter as per the computer vendor website.
Please replace VERSION with the latest version as displayed from the
computer vendor's website in lowercase.
Tag: bios-outdated-VERSION
Use case: A BIOS version older than the latest was confirmed to be
installed on the computer of the original reporter as per the computer
vendor website. Please replace VERSION with the latest version as
displayed from the computer vendor's website in lowercase.
Tag: latest-firmware-HARDWARE-VERSION
Use case: The latest firmware version was confirmed to be installed on
the hardware of the original reporter as per the hardware vendor
website. This tag relates to anything else that isn't a computer
(routers, solid state drive, etc.). Please replace HARDWARE with the
hardware type (router, ssd, etc.). Please replace VERSION with the
latest version as displayed from the vendor's website in lowercase.
Tag: firmware-outdated-HARDWARE-VERSION
Use case: A firmware version older than the latest was confirmed to be
installed on the hardware of the original reporter as per the hardware
vendor website. This tag relates to anything that isn't a computer
(routers, solid state drive, etc.). Please replace HARDWARE with the
hardware type (router, ssd, etc.). Please replace VERSION with the
latest version as displayed from the vendor's website in lowercase.

Set B
Tag: latest-bios
Use case: The latest BIOS version was confirmed to be installed on the
hardware of the original reporter as per the computer vendor website.
Tag: bios-outdated
Use case: A BIOS version older than the latest was confirmed to be
installed on the hardware of the original reporter as per the computer
vendor website.
Tag: latest-firmware
Use case: The latest firmware version was confirmed to be installed on
the hardware of the original reporter as per the hardware vendor
website. This tag relates to anything else that isn't a computer
(routers, solid state drive, etc.).
Tag: firmware-outdated
Use case: A firmware version older than the latest was confirmed to be
installed on the hardware of the original reporter as per the hardware
vendor website. This tag relates to anything else that isn't a
computer (routers, solid state drive, etc.).

Set A
PROS:
1) Maximizes information detail and value of the tag, given it is as
specific as possible.
2) Avoids the "Momento effect", where one puts a more generic tag
down, comes back later to the report and forget what the hardware,
and/or version was specifically, and then have to chase it all down
again.
3) Eliminates confusion for those unfamiliar with the use of the tag.
4) Puts in place a system that scales with Launchpad if/when Launchpad
searching is extended to include more granular searching. AFAIK, it
presently isn't fully extended in this way. Also, Google Advanced
Search wasn't terribly helpful doing the granular searching I've
attempted.
CONS:
1) Has a minimal amount of interpretation as to what constitutes the
version. For example, some vendors present the version in two
different formats simultaneously.
2) As Launchpad doesn't accept upper case characters in tags, one has
to convert uppercase version presentations to lowercase.
3) Requires a modest level of effort to maintain.

Set B
PROS:
1) Provides a level of value for the tag, ensuring that as of the date
the tag was applied, the original reporter's BIOS version was cross
checked against the vendor's website (not 3rd party effort sites).
2) Eliminates the interpretive nature of how to present the HARDWARE
or VERSION portion of the tag.
3) Easier to apply the tag.
CONS:
1) Doesn't maximize the value of the tag as the reader doesn't know
which version of the BIOS/firmware was applied without digging through
the report, and then confirming that from the vendor's website.
2) Regarding latest-firmware, the reader doesn't know what hardware it
applies to, or the version.

Personally, I prefer Set A given its value maximization proposition.

Despite this, a highly effective, generalized triaging statement for
updating the BIOS that would be placed in
https://wiki.ubuntu.com/Bugs/Responses to go along with this proposed
change:
[START]
As per your computer vendor's website, an update to your buggy,
insecure, and outdated BIOS is available. If you update to this
following https://help.ubuntu.com/community/BIOSUpdate does it change
anything?

For more on BIOS updates, please see
https://help.ubuntu.com/community/ReportingBugs.

Please note, your current BIOS is already in the Bug Description, so
posting this on the old BIOS would not be helpful.

Also, you don't have to create a new bug report after updating.

Once the BIOS is updated, if the problem is still reproducible:
1) Please provide the output of the following terminal command (not
perform an apport-collect):
sudo dmidecode -s bios-version && sudo dmidecode -s bios-release-date
2) Please make a comment specifically advising on if there was an
improvement or not.
3) Please mark this report Status New.

If the problem is no longer reproducible, please mark the Status Invalid.

Thank you for your understanding.
[END] * NOTE: While not required, as a convenience to the original
reporter, one may put the URL of where the update is located, and the
version number specifically found.

Motivation

Speaking to the motivation for this, I've been utilizing it via my
triaging efforts of hardware related reports for the last few years,
and found it to be of high value for many reasons:
1) The list of issues across hardware types an outdated BIOS and
firmware present is vast, technically quirky, and outright dangerous
from a security perspective. While I'm sure many are already familiar,
I would like to provide a non-exhaustive, yet most common list here
for reference:
+ Computer BIOS/firmware (affecting nearly everything, from general OS
performance, suspend/hibernate not working, kernel panics, to specific
device functionality misbehavior like touchpads, WiFi, keyboard,
graphics, RAID controllers, borked iDRAC presentation, etc.)
+ CF Card Readers
+ Solid State Drives
+ Hard Disk Drives
+ USB Controllers
+ DVD/CD Drives
+ Routers
2) Reports on Launchpad have been resolved by a BIOS, and/or hardware
firmware update.
3) Folks updating ahead of time have prevented unnecessary reports
from being filed to begin with.
4) Clear up confusion as to the purpose of what the tags mean.
5) Eliminate upstream hardware developer objections when they notice
or suspect outdated firmware/BIOS, advise to update, and then they are
never heard from again as a perceived trivial detail was missed before
filing upstream.
6) Avoid embarrassment on behalf of the original reporter who would
miss a perceived trivial detail before filing upstream.
7) Reduces the strain on finite developer resources from investigating
BIOS/firmware bugs that are remedied by updating it before one reports
the issue.
8) Showing interest in the update level of BIOS/firmware is
demonstrating a strong security awareness of the Ubuntu Community, and
providing further evidence Ubuntu is the secure choice for both
personal, and enterprise use.

The usual objections to applying either firmware or BIOS updates in
the first place, or at all, are mostly discussed in:
1) https://help.ubuntu.com/community/ReportingBugs#Hardware_bug_reports_.28linux_kernel.2C_xorg.2C_sound.2C_etc..29
2) https://help.ubuntu.com/community/BIOSUpdate?action=show&redirect=BiosUpdate#FAQ
3) TBD is documentation regarding how having outdated BIOS/firmware is
a security issue to be taken seriously in remedying.

I've certainly intended to be thoughtful, valuable, technically
detailed, and provide an easily implementable proposal, and hope you
find this so also.

What do you think?

Christopher M. Penalver
E-Mail: christopher.m.penalver@xxxxxxxxx