From: Borislav Petkov <[email protected]>
This is for the case where we need to set feature flags late, like, for
example, after late microcode patch has been loaded which has enabled
new CPUID bits.
This has no effect on alternatives patching.
Signed-off-by: Borislav Petkov <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Peter Zijlstra <[email protected]>
---
arch/x86/kernel/cpu/common.c | 17 +++++++++++++++++
arch/x86/kernel/cpu/cpu.h | 3 +++
2 files changed, 20 insertions(+)
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -724,6 +724,23 @@ static void apply_forced_caps(struct cpu
}
}
+/*
+ * This late synchronization of CPU caps has no effect on alternatives patching
+ * but updates the visible feature bits per CPU.
+ */
+void cpu_caps_sync_late(void)
+{
+ int cpu;
+
+ lockdep_assert_cpus_held();
+
+ for_each_online_cpu(cpu) {
+ struct cpuinfo_x86 *c = &cpu_data(cpu);
+
+ apply_forced_caps(c);
+ }
+}
+
void get_cpu_cap(struct cpuinfo_x86 *c)
{
u32 eax, ebx, ecx, edx;
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -46,5 +46,8 @@ extern const struct cpu_dev *const __x86
*const __x86_cpu_dev_end[];
extern void get_cpu_cap(struct cpuinfo_x86 *c);
+
+extern void cpu_caps_sync_late(void);
+
extern void cpu_detect_cache_sizes(struct cpuinfo_x86 *c);
#endif /* ARCH_X86_CPU_H */
On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> This is for the case where we need to set feature flags late, like, for
> example, after late microcode patch has been loaded which has enabled
> new CPUID bits.
>
> This has no effect on alternatives patching.
In other words, if you use late microcode loading for getting IBRS, you
don't get ALTERNATIVE patching and its benefits?
I'll also profess some microcode ignorance here. Is "late microcode
patching" *all* of the stuff we do from the OS, or do we have early and
late Linux loading in addition to what the BIOS can do?
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
>
> I'll also profess some microcode ignorance here. Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in addition to what the BIOS can do?
the early boot loader level stuff is much better generally (but does not work when the microcode comes out after the system booted... like really long uptimes)
On Tue, 9 Jan 2018, Dave Hansen wrote:
> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > This is for the case where we need to set feature flags late, like, for
> > example, after late microcode patch has been loaded which has enabled
> > new CPUID bits.
> >
> > This has no effect on alternatives patching.
>
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
>
> I'll also profess some microcode ignorance here. Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in addition to what the BIOS can do?
IBRS wont use alternatives for that and various other reasons. It has to be
static key based so we can patch it late
Thanks,
tglx
On Wed, 10 Jan 2018, Van De Ven, Arjan wrote:
> > In other words, if you use late microcode loading for getting IBRS, you
> > don't get ALTERNATIVE patching and its benefits?
> >
> > I'll also profess some microcode ignorance here. Is "late microcode
> > patching" *all* of the stuff we do from the OS, or do we have early and
> > late Linux loading in addition to what the BIOS can do?
>
> the early boot loader level stuff is much better generally (but does not
> work when the microcode comes out after the system booted... like really
> long uptimes)
That stuff indeed would be way simpler w/o the late support, but the fact
that the microcode for this might reach the user way later than the kernel
support makes it almost a must to support the late loading.
Thanks,
tglx
> On Jan 9, 2018, at 5:47 PM, Thomas Gleixner <[email protected]> wrote:
>
> On Wed, 10 Jan 2018, Van De Ven, Arjan wrote:
>>> In other words, if you use late microcode loading for getting IBRS, you
>>> don't get ALTERNATIVE patching and its benefits?
>>>
>>> I'll also profess some microcode ignorance here. Is "late microcode
>>> patching" *all* of the stuff we do from the OS, or do we have early and
>>> late Linux loading in addition to what the BIOS can do?
>>
>> the early boot loader level stuff is much better generally (but does not
>> work when the microcode comes out after the system booted... like really
>> long uptimes)
>
> That stuff indeed would be way simpler w/o the late support, but the fact
> that the microcode for this might reach the user way later than the kernel
> support makes it almost a must to support the late loading.
How hard would it be to add a late alternative feature? Concretely, we'd have a list of "late" cpufeatures. When we scan the alternative list, if we find a late feature, we copy it to some other list that isn't discarded, and we also copy its replacement (and relocate it eagerly, since we'll lose the offset).
* Dave Hansen <[email protected]> wrote:
> On 01/09/2018 05:06 PM, Thomas Gleixner wrote:
> > This is for the case where we need to set feature flags late, like, for
> > example, after late microcode patch has been loaded which has enabled
> > new CPUID bits.
> >
> > This has no effect on alternatives patching.
>
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
>
> I'll also profess some microcode ignorance here. Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in addition to what the BIOS can do?
So would it be really unreasonable to say that if a microcode update changes CPU
flags an initrd rebuild and a reboot is required? It's not like microcode updates
are _that_ frequent - in fact they tend to be much _less_ frequent in a system's
life time than kernel updates.
So all of this 'late loading' and CPU flag splitting complexity seems unnecessary
to me: we should be glad we do early microcode loading now, and should embrace it.
Changing CPU features way after the CPU has booted up is possible, and we could in
theory extend code patching to work 'late' as well, but given how infrequent all
this is bound to be in practice I fear it's all going to be a big, seldom tested,
often broken mess, with no real benefit to users.
Thanks,
Ingo
On Tue, 9 Jan 2018, Andy Lutomirski wrote:
> > On Jan 9, 2018, at 5:47 PM, Thomas Gleixner <[email protected]> wrote:
> >
> > On Wed, 10 Jan 2018, Van De Ven, Arjan wrote:
> >>> In other words, if you use late microcode loading for getting IBRS, you
> >>> don't get ALTERNATIVE patching and its benefits?
> >>>
> >>> I'll also profess some microcode ignorance here. Is "late microcode
> >>> patching" *all* of the stuff we do from the OS, or do we have early and
> >>> late Linux loading in addition to what the BIOS can do?
> >>
> >> the early boot loader level stuff is much better generally (but does not
> >> work when the microcode comes out after the system booted... like really
> >> long uptimes)
> >
> > That stuff indeed would be way simpler w/o the late support, but the fact
> > that the microcode for this might reach the user way later than the kernel
> > support makes it almost a must to support the late loading.
>
> How hard would it be to add a late alternative feature? Concretely, we'd
> have a list of "late" cpufeatures. When we scan the alternative list, if
> we find a late feature, we copy it to some other list that isn't
> discarded, and we also copy its replacement (and relocate it eagerly,
> since we'll lose the offset).
It shouldn't be rocket science, but that's not for now. And yes, we should
do it.
Thanks,
tglx
On Wed, Jan 10, 2018 at 07:20:13AM +0100, Ingo Molnar wrote:
> it be really unreasonable to say that if a microcode update changes CPU
> flags an initrd rebuild and a reboot is required? It's not like microcode updates
> are _that_ frequent - in fact they tend to be much _less_ frequent in a system's
> life time than kernel updates.
>
> So all of this 'late loading' and CPU flag splitting complexity seems unnecessary
> to me: we should be glad we do early microcode loading now, and should embrace it.
>
> Changing CPU features way after the CPU has booted up is possible, and we could in
> theory extend code patching to work 'late' as well, but given how infrequent all
> this is bound to be in practice I fear it's all going to be a big, seldom tested,
> often broken mess, with no real benefit to users.
Agreed: we support that late patching for those use cases where machines
run for a long time, simulating all kinds of crap. And frankly, if
those things need to get IBRS all of a sudden and *not* reboot, then
something's wrong with the whole contraption setup.
So yes, I'd vote too for supporting only early IBRS and not do the late
thing now. Maybe later, if there's, like, a really compelling use case.
I will have to do the late thing for our old kernels which don't have
early loading but that would be a one-off and my problem.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On Wed, 10 Jan 2018, Borislav Petkov wrote:
> On Wed, Jan 10, 2018 at 07:20:13AM +0100, Ingo Molnar wrote:
> > it be really unreasonable to say that if a microcode update changes CPU
> > flags an initrd rebuild and a reboot is required? It's not like microcode updates
> > are _that_ frequent - in fact they tend to be much _less_ frequent in a system's
> > life time than kernel updates.
> >
> > So all of this 'late loading' and CPU flag splitting complexity seems unnecessary
> > to me: we should be glad we do early microcode loading now, and should embrace it.
> >
> > Changing CPU features way after the CPU has booted up is possible, and we could in
> > theory extend code patching to work 'late' as well, but given how infrequent all
> > this is bound to be in practice I fear it's all going to be a big, seldom tested,
> > often broken mess, with no real benefit to users.
>
> Agreed: we support that late patching for those use cases where machines
> run for a long time, simulating all kinds of crap. And frankly, if
> those things need to get IBRS all of a sudden and *not* reboot, then
> something's wrong with the whole contraption setup.
>
> So yes, I'd vote too for supporting only early IBRS and not do the late
> thing now. Maybe later, if there's, like, a really compelling use case.
/me exposes it to the flame-thrower