[MIR] intel-microcode & iucode-tool (multiverse -> restricted)

In terms of bug subscribers, I'm hoping that ~canonical-kernel-team & ~intel-team can be jointly subscribed to both packages.

Jamie, I'll hand off to you because I'm not versed in whatever security implications exist here.

I reviewed iucode-tool version 1.1.1-1 as checked into vivid. This should
not be considered a full security audit but rather a quick gauge of
maintainability.

- iucode-tool manages and loads firmware for Intel CPUs
- Build-Depends: debhelper, autotools-dev, automake, autoconf
- No cryptography
- No networking
- Does not daemonize
- No pre/post inst/rm
- No initscripts
- No dbus services
- No setuid
- One binary, iucode_tool, and symlink iucode-tool
- No sudo fragments
- No udev rules
- No cronjobs
- No test suite, not really a surprise
- Clean build logs

- No subprocesses spawned
- Memory management is careful
- File names are given by the platform
- Logging looks safe
- No environment variables used
- No cryptography
- No networking
- No privileged portions of code
- No temporary files
- No WebKit
- No PolicyKit
- No JavaScript
- Clean cppcheck

iucode-tool is short and sweet: careful, methodical, some nice helper
routines, good comments.

Security team ACK for promoting to restricted or main as appropriate.

I reviewed intel-microcode version 2.20140913.1ubuntu2 as checked into
vivid. This should not be considered a full security audit but rather a
quick gauge of maintainability.

- intel-microcode provides scripts to load microcode during early boot and
  intel-supplied microcode
- Build-Depends: debhelper, iucode-tool
- No cryptography
- No networking
- Does not daemonize
- No pre/post inst/rm
- No init scripts
- No dbus services
- No setuid
- No binaries
- No sudo fragments
- No udev rules
- No test suite, unsurprisingly
- No cronjobs
- Clean build logs

- Subprocesses are spawned extensively, shell scripts; nearly all looked
  safe
- No memory management
- Files written to are controlled by platform, e.g.
  /sys/devices/system/cpu/cpu*/microcode/reload and
  /sys/devices/system/cpu/microcode/reload
- No environment variables
- No cryptography
- No networking
- No privileged portions of code
- The only temporary file handling is in a maintainer-only script
  debian/diff-latest-pack.sh -- it has predictable /tmp/ names; not a big
  deal if the packager using this tool is aware of the limitation.
- No WebKit
- No PolicyKit
- No JavaScript
- slight problem with static analysis, line 92 of debian/initramfs.hook is
  probably a bug.

Here's the two issues I found with this package; the first is unlikely to
be a real problem in actual service and the second hasn't actually caused
problems despite being in deployed use -- but it's probably a bug all the
same:

debian/diff-latest-pack.sh -- it has predictable /tmp/ names; not a big
deal if the packager using this tool is aware of the limitation.

Line 92 of debian/initramfs.hook is probably a bug:
if $(dpkg --compare-versions 3.9 le ${version}) ; then

Please fix at the earliest convenience.

Security team ACK for migrating to restricted or main as appropriate.

I am the Debian upstream for both packages (intel-microcode and iucode-tool), and upstream author for iucode-tool.

Thank you for the kind comments on iucode-tool :-)

As for intel-microcode, you guys are dealing with an outdated package version. The new one in Debian addresses the Haswell microcode update issue by switching to enforced early initramfs mode updates...

This simplified the packaging a lot, but it also means there were extensive changes to all scripts, so the intel-microcode security analysis likely needs to be redone when you resync with Debian.

Also, the intel-microcode package version you're considering can be a hazard when dealing with Intel microcode updates with visible effects at the ISA level, like the Haswell "disable TSX" microcode update. It can result in an unusable system, as your QA team found out, which forced you guys to revert to the previous Intel microcode update data.

The newer version of intel-microcode in Debian enforces the safe use of early microcode updates, which allows the use of Intel microcode update data 20140913 and newer. You should consider a resync as soon as pratical.

iucode-tool looks fine from a packaging/maintenance perspective. I see that Henrique (the upstream & Debian maintainer) is watching Ubuntu bugs, which is awesome, thanks! But as a matter of policy, we like to see a team bug subscriber to Ubuntu bugs as well, for whomever agrees to look after the package in Ubuntu.

Dimitri, what team wanted this in restricted? Foundations?

As for intel-microcode, looks like it is going to be updated soon? I'll wait to review until after, then.

On 3 December 2014 at 11:30, Henrique de Moraes Holschuh
<email address hidden> wrote:
> I am the Debian upstream for both packages (intel-microcode and iucode-
> tool), and upstream author for iucode-tool.
>
> Thank you for the kind comments on iucode-tool :-)
>
> As for intel-microcode, you guys are dealing with an outdated package
> version. The new one in Debian addresses the Haswell microcode update
> issue by switching to enforced early initramfs mode updates...
>
> This simplified the packaging a lot, but it also means there were
> extensive changes to all scripts, so the intel-microcode security
> analysis likely needs to be redone when you resync with Debian.
>
> Also, the intel-microcode package version you're considering can be a
> hazard when dealing with Intel microcode updates with visible effects at
> the ISA level, like the Haswell "disable TSX" microcode update. It can
> result in an unusable system, as your QA team found out, which forced
> you guys to revert to the previous Intel microcode update data.
>
> The newer version of intel-microcode in Debian enforces the safe use of
> early microcode updates, which allows the use of Intel microcode update
> data 20140913 and newer. You should consider a resync as soon as
> pratical.
>

Right, this was pointed out to me. I'll make sure the updated package
is merged in properly before proceeding with this.

--
Regards,

Dimitri.

On 3 December 2014 at 14:30, Michael Terry <email address hidden> wrote:
> iucode-tool looks fine from a packaging/maintenance perspective. I see
> that Henrique (the upstream & Debian maintainer) is watching Ubuntu
> bugs, which is awesome, thanks! But as a matter of policy, we like to
> see a team bug subscriber to Ubuntu bugs as well, for whomever agrees to
> look after the package in Ubuntu.
>
> Dimitri, what team wanted this in restricted? Foundations?
>

~intel-team & ~canonical-kernel hopefully.

I'll be adding integration in the installer. Patches pending review.

> As for intel-microcode, looks like it is going to be updated soon? I'll
> wait to review until after, then.
>
> ** Changed in: iucode-tool (Ubuntu)
> Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1388889
>
> Title:
> [MIR] intel-microcode & iucode-tool (multiverse -> restricted)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/intel/+bug/1388889/+subscriptions

--
Regards,

Dimitri.

latest intel-microcode synced from Debian into Vivid.
dpkg compare-versions bug is rectified in that version.
predictable tmp name is still there, but it's packager's script only as pointed out.

On Thu, 04 Dec 2014, Dimitri John Ledkov wrote:
> On 3 December 2014 at 11:30, Henrique de Moraes Holschuh
> <email address hidden> wrote:
> > I am the Debian upstream for both packages (intel-microcode and iucode-
> > tool), and upstream author for iucode-tool.
> >
> > Thank you for the kind comments on iucode-tool :-)
> >
> > As for intel-microcode, you guys are dealing with an outdated package
> > version. The new one in Debian addresses the Haswell microcode update
> > issue by switching to enforced early initramfs mode updates...
> >
> > This simplified the packaging a lot, but it also means there were
> > extensive changes to all scripts, so the intel-microcode security
> > analysis likely needs to be redone when you resync with Debian.
> >
> > Also, the intel-microcode package version you're considering can be a
> > hazard when dealing with Intel microcode updates with visible effects at
> > the ISA level, like the Haswell "disable TSX" microcode update. It can
> > result in an unusable system, as your QA team found out, which forced
> > you guys to revert to the previous Intel microcode update data.
> >
> > The newer version of intel-microcode in Debian enforces the safe use of
> > early microcode updates, which allows the use of Intel microcode update
> > data 20140913 and newer. You should consider a resync as soon as
> > pratical.
>
> Right, this was pointed out to me. I'll make sure the updated package
> is merged in properly before proceeding with this.

I just ask that you guys notify me of any issues you find, so that I can fix
them post-haste in Debian as well.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

intel-microcode is fine from my side, but Henrique mentioned that the packaging and scripts changed enough in the latest version that Seth might want to look it over again. So assigning to Seth for a final OK.

Thanks for the quick turn-around, the new version of intel-microcode looks good -- it fixed the little issue I spotted earlier and feels simpler.

Security team ACK for promoting intel-microcode to main or restricted as appropriate.

Thanks

Seeded into ubuntu.vivid server-ship, ship-live, usb-ship-live to have intel-microcode in the package pool on all images.
ubuntu-drivers update will be next.

Override component to main
intel-microcode 3.20140913.1 in vivid: multiverse/admin -> main
intel-microcode 3.20140913.1 in vivid amd64: multiverse/admin/extra/100% -> main
intel-microcode 3.20140913.1 in vivid i386: multiverse/admin/extra/100% -> main
3 publications overridden.

Override component to main
iucode-tool 1.1.1-1 in vivid: multiverse/utils -> main
iucode-tool 1.1.1-1 in vivid amd64: multiverse/utils/optional/100% -> main
iucode-tool 1.1.1-1 in vivid i386: multiverse/utils/optional/100% -> main
3 publications overridden.

Override component to restricted
intel-microcode 3.20140913.1 in vivid: main/admin -> restricted
intel-microcode 3.20140913.1 in vivid amd64: main/admin/extra/100% -> restricted
intel-microcode 3.20140913.1 in vivid i386: main/admin/extra/100% -> restricted
3 publications overridden.

Override component to restricted
iucode-tool 1.1.1-1 in vivid: main/utils -> restricted
iucode-tool 1.1.1-1 in vivid amd64: main/utils/optional/100% -> restricted
iucode-tool 1.1.1-1 in vivid i386: main/utils/optional/100% -> restricted
3 publications overridden.

I'm unsubscribing the ubuntu-archive team from this bug since the intel task is still open and shows up on our to-do list. Feel free to resubscribe us if there's still some action for us to take here.

sorry for any inconvenience cause. this is operating as expected.