increase UCODE_SIZE_MAX from 32kB to 4MB in sys/dev/cpuctl/cpuctl.c to allow microcode update on Intel 6th+ gen CPUs

[op]

Summary

HBSD: increase UCODE_SIZE_MAX from 32kB to 4MB in sys/dev/cpuctl/cpuctl.c

The lastest microcode update for Intel 6th (Skylake) generation CPU is
bigger than the current hardcoded limit in cpuctl.

-rw-r--r-- 1 root wheel 97280 Nov 9 21:35 m36506e3_0000009d_0000009e.fw
-rw-r--r-- 1 root wheel 97280 Nov 9 21:35 mc0406e3_0000009d_0000009e.fw

So, bump this limit to 4MB, to allow to perform the microcode update.

Tested-on: 10-STABLE + Intel Core i7-6700
Sponsored-by: HardenedBSD Project
FreeBSD-PR: 214369
Signed-off-by: Oliver Pinter <[e-mail]>
CC: [e-mail]
CC: [e-mail]
CC: [e-mail]
CC: [e-mail]

Test Plan

Apply the patch, recompile the kernel, install the new kernel, and perform the update with cpucontrol -u

[olevole_olevole.ru]

Probably a good idea to make it tunable and also, it would be nice if the system checks the amount of firmware and noticed message about limit exceed, instead of 'Invalid argument'

[kib]

In D8486#176439, @olevole_olevole.ru wrote:

Probably a good idea to make it tunable and also, it would be nice if the system checks the amount of firmware and noticed message about limit exceed, instead of 'Invalid argument'

I do not see it useful to have the safety belt tunable. Initially, a low value for the constant was a reasonable compromise because contigmalloc(9) was used for firmware image which was supplied to CPU. Some algorithms for vendors used contigmalloc(9) due to misunderstanding, some due to lack or uncertainty in the documentation.

Now I think we only need a safety value, and do not need to help contigmalloc(9). So I think that some large enough value, e.g. 4M, is a good choice to disallow userspace to abuse kernel malloc, while providing good room for future cpu bug vectors.

[op]

Updated the limit to 4MB as proposed by kib@.