Re: [Xen-devel] [PATCH v2 4/4] x86/microcode: Support builtin CPU microcode

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.01.2020 21:06, Eslam Elnikety wrote:
> On 20.12.19 11:12, Jan Beulich wrote:
>> On 19.12.2019 23:11, Eslam Elnikety wrote:
>>> On 18.12.19 13:42, Jan Beulich wrote:
>>>> On 18.12.2019 02:32, Eslam Elnikety wrote:
>>>>> --- /dev/null
>>>>> +++ b/xen/arch/x86/microcode/Makefile
>>>>> @@ -0,0 +1,46 @@
>>>>> +# Copyright (C) 2019 Amazon.com, Inc. or its affiliates.
>>>>> +# Author: Eslam Elnikety <elnikety@xxxxxxxxxx>
>>>>> +#
>>>>> +# This program is free software; you can redistribute it and/or modify
>>>>> +# it under the terms of the GNU General Public License as published by
>>>>> +# the Free Software Foundation; either version 2 of the License, or
>>>>> +# (at your option) any later version.
>>>>> +#
>>>>> +# This program is distributed in the hope that it will be useful,
>>>>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>>>>> +# GNU General Public License for more details.
>>>>> +
>>>>> +# Remove quotes and excess spaces from configuration strings
>>>>> +UCODE_DIR=$(strip $(subst $\",,$(CONFIG_BUILTIN_UCODE_DIR)))
>>>>> +UCODE_AMD=$(strip $(subst $\",,$(CONFIG_BUILTIN_UCODE_AMD)))
>>>>> +UCODE_INTEL=$(strip $(subst $\",,$(CONFIG_BUILTIN_UCODE_INTEL)))
>>>>> +
>>>>> +# AMD and INTEL microcode blobs. Use 'wildcard' to filter for existing 
>>>>> blobs.
>>>>> +amd-blobs := $(wildcard $(addprefix $(UCODE_DIR),$(UCODE_AMD)))
>>>>> +intel-blobs := $(wildcard $(addprefix $(UCODE_DIR),$(UCODE_INTEL)))
>>>>> +
>>>>> +ifneq ($(amd-blobs),)
>>>>> +obj-y += ucode_amd.o
>>>>> +endif
>>>>> +
>>>>> +ifneq ($(intel-blobs),)
>>>>> +obj-y += ucode_intel.o
>>>>> +endif
>>>>> +
>>>>> +ifeq ($(amd-blobs)$(intel-blobs),)
>>>>> +obj-y += ucode_dummy.o
>>>>> +endif
>>>>> +
>>>>> +ucode_amd.o: Makefile $(amd-blobs)
>>>>> + cat $(amd-blobs) > $@.bin
>>>>> + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 --rename-section 
>>>>> .data=.builtin_amd_ucode,alloc,load,readonly,data,contents $@.bin $@
>>>>> + rm -f $@.bin
>>>>> +
>>>>> +ucode_intel.o: Makefile $(intel-blobs)
>>>>> + cat $(intel-blobs) > $@.bin
>>>>> + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 --rename-section 
>>>>> .data=.builtin_intel_ucode,alloc,load,readonly,data,contents $@.bin $@
>>>>> + rm -f $@.bin
>>>>
>>>> This can be had with a pattern rule (with the vendor being the stem)
>>>> and hence without duplication, I think.
>>>>
>>>> Also - is simply concatenating the blobs reliable enough? There's no
>>>> build time diagnostic that the result would actually be understood
>>>> at runtime.
>>>>
>>>
>>> Concatenation is reliable (as long as the individual microcode blobs are
>>> not malformed, and in that case the builtin is not making matters worse
>>> compared to presenting the malformed update via <integer> | scan).
>>
>> A malformed update found the other way is a bug in the tools
>> constructing the respective images. A malformed built-in
>> update is a bug in the Xen build system. The put the question
>> differently: Is it specified somewhere that the blobs all have
>> to have certain properties, which the straight concatenation
>> relies upon?
>>
> 
> Refer to ( https://www.kernel.org/doc/Documentation/x86/microcode.txt ). 
> AuthenticAMD.bin and GenuineIntel.bin are both concatenations of 
> individual microcode blobs.

Well, yes, and from practical observations this is good enough. But
observe e.g. how that paragraph starts with "Here's a crude example
...".

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel