On Fri, Aug 08, 2014 at 10:50:57AM -0300, Henrique de Moraes Holschuh wrote:
> On Fri, 08 Aug 2014, Borislav Petkov wrote:
> > If someone tries to load a microcode blob which has been split and so
> > on, then we should refuse loading. We want to accept microcode from the
> > vendor and nothing else glued together.
>
> I don't quite get why we should refuse microcode
Because the blob from the official location passes internal validation, I'd
strongly assume. Everything else doesn't.
> that has been split by userspace when the Intel SDM explicitly states
> that tools can do that if there is a need,
Where?
> In these last two weeks I tried to look around for microcode loader
> implementantions, and now I believe we will *never* see microcode with the
> current version of the extended signatures specification. The loaders in
> the field are just too broken, Intel might as well come up with a new and
> enhanced design that doesn't have so many sharp edges, since nearly everyone
> will have to patch their loaders anyway.
You can't just assume that just because implementations are faulty there
- they should adhere to the SDM and it is authoritative. If the extended
signatures are really needed at some point, implementations will have to
be fixed.
> I will respin the patch without the %1024 comment. Note that I never
> *removed* any test, we never tested for %1024 in the first place
And I'm saying we should if we're loading the official blob.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
