On Fri, 2021-02-26 at 06:57 -0500, Paolo Bonzini wrote:
> + depends on KVM && IA32_FEAT_CTL
Hm, why IA32_FEAT_CTL?
Amazon Development Centre (London) Ltd. Registered in England and Wales with
registration number 04543232 with its registered office at 1 Principal Place,
Worship Street, L
On Fri, 2021-02-26 at 06:57 -0500, Paolo Bonzini wrote:
> The Xen hypercall interface adds to the attack surface of the hypervisor
> and will be used quite rarely. Allow compiling it out.
>
> Suggested-by: Christoph Hellwig
> Cc: David Woodhouse
> Signed-off-by: Paolo Bonzini
Reviewed-by: Dav
On Fri, 2021-02-26 at 05:08 -0500, Paolo Bonzini wrote:
> A missing flush would cause the static branch to trigger incorrectly.
>
> Cc: David Woodhouse
> Signed-off-by: Paolo Bonzini
Reviewed-by: David Woodhouse
Thanks.
Amazon Development Centre (London) Ltd. Registered in England and Wa
On Wed, 2021-02-10 at 13:13 -0800, Sean Christopherson wrote:
> On Wed, Feb 10, 2021, Woodhouse, David wrote:
> > On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote:
> > So it isn't clear the additionally padding really buys us anything; if
> > we play this ga
On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote:
> The Xen shinfo selftest uses '40' when setting the GPA of the vCPU info
> struct, but checks for the result at '0x40'. Arbitrarily use the hex
> version to resolve the bug.
>
> Fixes: 8d4e7e80838f ("KVM: x86: declare Xen HVM shared i
On Wed, 2021-02-10 at 10:26 -0800, Sean Christopherson wrote:
> Add a 2 byte pad to struct compat_vcpu_info so that the sum size of its
> fields is actually 64 bytes. The effective size without the padding is
> also 64 bytes due to the compiler aligning evtchn_pending_sel to a 4-byte
> boundary, b
On Wed, 2021-02-10 at 17:06 +, Julien Grall wrote:
> From: Julien Grall
>
> After Commit 3499ba8198cad ("xen: Fix event channel callback via
> INTX/GSI"), xenbus_probe() will be called too early on Arm. This will
> recent to a guest hang during boot.
>
> If there hang wasn't there, we would
On Mon, 2021-02-08 at 12:15 -0800, Sean Christopherson wrote:
> Use hva_t, a.k.a. unsigned long, for the local variable that holds the
> hypercall page address. On 32-bit KVM, gcc complains about using a u64
> due to the implicit cast from a 64-bit value to a 32-bit pointer.
>
> arch/x86/kvm/xe
On Tue, 2020-12-01 at 16:45 -0800, Dexuan Cui wrote:
> The commit f36a74b9345a itself is good, but it causes a panic in a
> Linux VM that runs on a Hyper-V host that doesn't have the 15-bit
> Extended APIC ID support:
> kernel BUG at arch/x86/kernel/apic/io_apic.c:2408!
>
> This happens becaus
On Tue, 2020-11-03 at 16:22 +0100, Thomas Gleixner wrote:
> Hi!
>
> On Tue, Nov 03 2020 at 22:31, lkp wrote:
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: b643128b917ca8f1c8b1e14af64ebdc81147b2d1 ("x86/ioapic: Use
> > irq_find_matching_fwspec() to find remapping irq
On Sat, 2018-03-03 at 09:54 +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 02, 2018 at 01:32:08PM -0800, Tim Chen wrote:
> >
> > Greg,
> >
> > I will like to propose backporting "x86/speculation: Use Indirect Branch
> > Prediction Barrier on context switch" from commit 18bf3c3e in upstream
> > to
On Tue, 2018-02-06 at 19:01 +0100, Paolo Bonzini wrote:
> On 06/02/2018 18:29, David Woodhouse wrote:
> > I've put together a linux-4.9.y branch at
> > http://git.infradead.org/retpoline-stable.git/shortlog/refs/heads/linux-4.9.y
> >
> > Most of it is fairly straightforward, apart from the IBPB
On Wed, 2018-01-31 at 13:05 -0800, Jim Mattson wrote:
> On Wed, Jan 31, 2018 at 1:00 PM, Paolo Bonzini wrote:
>
> > Yes, but how would moving the field into struct loaded_vmcs do anything?
> > Only vmon/vmoff would change anything in vmx->nested.vmcs02.
>
> My suggestion was that nested_vmx_mer
On Sun, 2018-01-28 at 10:56 +0100, Ingo Molnar wrote:
>
> What tree is this patch against? It doesn't apply to linus's latest, nor to
> tip:master.
It's in my tree at
http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb
which is gradually being finalized and flushe
On Tue, 2018-01-23 at 17:28 -0800, Dave Hansen wrote:
> On 01/23/2018 05:23 PM, Woodhouse, David wrote:
> >
> > On Tue, 2018-01-23 at 10:43 -0800, Dave Hansen wrote:
> ...
> >
> > >
> > > >
> > > > /* Intel-defined CPU f
On Tue, 2018-01-23 at 14:49 -0800, Andi Kleen wrote:
> > Not sure. Maybe to start, the answer might be to allow it to be set for
> > the ultra-paranoid, but in general don't enable it by default. Having it
> > enabled would be an alternative to someone deciding to disable SMT, since
> > that woul
On Tue, 2018-01-23 at 10:41 -0800, Dave Hansen wrote:
> On 01/23/2018 08:52 AM, David Woodhouse wrote:
> > When they advertise the IA32_ARCH_CAPABILITIES MSR and it has the RDCL_NO
> > bit set, they don't need KPTI either.
>
> Also, I hate to ask... Have you tested this patch?
Nope. I deliberate
On Tue, 2018-01-23 at 19:31 +0100, Greg KH wrote:
> On Tue, Jan 23, 2018 at 10:27:24AM -0800, Dave Hansen wrote:
> >
> > On 01/23/2018 08:52 AM, David Woodhouse wrote:
> > >
> > > +#define MSR_IA32_ARCH_CAPABILITIES 0x010a
> > > +#define ARCH_CAP_RDCL_NO (1 << 0) /* Not suscep
On Tue, 2018-01-23 at 10:12 -0600, Tom Lendacky wrote:
>
> >> +.macro UNRESTRICT_IB_SPEC
> >> + ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_IBRS
> >> + PUSH_MSR_REGS
> >> + WRMSR_ASM $MSR_IA32_SPEC_CTRL, $0, $0
> >
> I think you should be writing 2, not 0, since I'm reasonably
> confide
On Mon, 2018-01-22 at 14:30 +0100, Greg Kroah-Hartman wrote:
> We kind of do, you can submit patches to UEFI, but I doubt that the
> processor-specific portions are actually present in the Tianocore code
> to be able to be patched.
This is just about which microcode your BIOS loads into the CPU be
On Sun, 2018-01-21 at 17:21 +0100, Ingo Molnar wrote:
>
> Because putting something like this into an ELF flag raises the question of
> who is
> allowed to set the flag - does a user-compiled binary count? If yes then it
> would
> be a trivial thing for local exploits to set the flag and turn
On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote:
> From: Tim Chen
I think this is probably From: Andi now rather than From: Tim?
We do need the series this far in order to have a full retpoline-based
mitigation, and I'd like to see that go in sooner rather than later.
There's a little
On Sat, 2018-01-20 at 12:28 -0800, Liran Alon wrote:
> Isn't it cleaner to check for "boot_cpu_has(X86_FEATURE_IBPB)" both
> in svm_vcpu_init_msrpm() and hardware_setup()?
Strictly speaking that's a different check. That's checking if we're
*using* IBPB, not if it exists.
Now that's probably OK h
On Sat, 2018-01-20 at 20:22 +0100, KarimAllah Ahmed wrote:
>
> @@ -6791,6 +6792,9 @@ static __init int hardware_setup(void)
> kvm_tsc_scaling_ratio_frac_bits = 48;
> }
>
> + if (boot_cpu_has(X86_FEATURE_SPEC_CTRL))
> + vmx_disable_intercept_for_msr(MSR
On Thu, 2018-01-18 at 16:28 +0100, Thomas Gleixner wrote:
> The machine check idtentry uses an indirect branch directly from the low
> level code. This evades the speculation protection.
>
> Replace it by a direct call into C code and issue the indirect call there
> so the compiler can apply the p
On Thu, 2018-01-18 at 21:01 +0900, Masami Hiramatsu wrote:
>
> +#define X86_INDIRECT_THUNK(reg)\
> + *(.text.__x86.indirect_thunk.##reg)
Note that we don't actually care about those being in their own
section, named after the register. That was just a hangover from the
initi
On Tue, 2018-01-16 at 11:22 +0100, Jiri Slaby wrote:
> On 01/15/2018, 01:35 PM, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch. If anyone has any objections, please let me know.
>
> May I ask if somebody has started the 4.4 port yet?
Razvan pushed that out yesterday:
http://git.infradead
On Sun, 2018-01-14 at 16:41 +0100, Borislav Petkov wrote:
> On Sat, Jan 13, 2018 at 05:27:30PM -0600, Tom Lendacky wrote:
> >
> > The PAUSE instruction is currently used in the retpoline and RSB filling
> > macros as a speculation trap. The use of PAUSE was originally suggested
> > because it sho
On Fri, 2018-01-12 at 19:07 -0600, Tom Lendacky wrote:
> The pause instruction is currently used in the retpoline and RSB filling
> macros as a speculation trap. The use of pause was originally suggested
> because it showed a very, very small difference in the amount of
> cycles/time used to execu
On Fri, 2018-01-12 at 09:03 -0800, Jim Mattson wrote:
> The point behind the IPBP in vmx_vcpu_load is to prevent one VCPU from
> steering the speculative execution of the next. If the VMCS address is
> recycled, vmx_vcpu_load doesn't realize that the VCPUs are different,
> and so it won't issue the
On Thu, 2018-01-11 at 21:03 -0800, Dave Hansen wrote:
> On 01/11/2018 07:01 PM, Raj, Ashok wrote:
> > On Thu, Jan 11, 2018 at 06:20:13PM -0800, Andy Lutomirski wrote:
> >> On Thu, Jan 11, 2018 at 5:52 PM, Raj, Ashok wrote:
>
> What's wrong with native_read_msr()?
> >>>
> >>> Yes, i think
On Fri, 2018-01-12 at 09:31 -0600, Tom Lendacky wrote:
>
> AMD will follow the specification that if cpuid ax=0x7, return rdx[26]
> is set, it will indicate both MSR registers and features are supported.
>
> But AMD also has a separate bit for IBPB (X86_FEATURE_PRED_CMD) alone.
> As all of the IB
On Fri, 2018-01-12 at 13:32 +0100, Borislav Petkov wrote:
> On Thu, Jan 11, 2018 at 05:32:19PM -0800, Ashok Raj wrote:
> > cpuid ax=0x7, return rdx bit 26 to indicate presence of both
> > IA32_SPEC_CTRL(MSR 0x48) and IA32_PRED_CMD(MSR 0x49)
>
> So why do we need two X86_FEATURE flags then?
AMD ha
> On Fri, 2018-01-12 at 12:15 +0100, Thomas Gleixner wrote:
> Fair enough. I surely like the below way more than the sloppy hackery from
> Andi which completely removed any form of documentation.
Be nice. Andi has been extremely helpful in testing and finding corner
cases here, and generally keepi
On Tue, 2018-01-09 at 18:26 -0800, Tim Chen wrote:
> Set IBRS upon kernel entrance via syscall and interrupts. Clear it
> upon exit.
In the former set of sites, you're going to want to stuff the RSB too.
The patch I sent out this morning adds the infrastructure you want for
that; we'll just want
On Thu, 2018-01-11 at 10:47 +0100, Borislav Petkov wrote:
> On Thu, Jan 11, 2018 at 10:32:31AM +0100, Peter Zijlstra wrote:
> >
> > can't you do lovely things like:
> >
> > volatile asm ("call __fill_rsb_thunk_%1" : : "r" (dummy))
> >
> > which would still let gcc select the register ?
I've
On Thu, 2018-01-11 at 09:49 +0100, Boris Petkov wrote:
> On January 11, 2018 9:42:38 AM GMT+01:00, Peter Zijlstra wrote:
> >Or we teach the alternative thing to patch in a jmp to end instead of
> >NOP padding the entire thing as soon as the jmp (3 bytes) fits ?
>
> Or, even better: use alternativ
On Wed, 2018-01-10 at 15:47 -0800, Tim Chen wrote:
>
> > +
> > + asm volatile (ALTERNATIVE("",
> > + __stringify(__FILL_RETURN_BUFFER(%0, %1,
> > _%=)),
> > + X86_FEATURE_RETPOLINE)
>
> We'll be patching in a fairly long set of inst
On Wed, 2018-01-10 at 15:22 -0800, David Lang wrote:
> I somewhat hate to ask this, but for those of us following at home, what does
> this add to the overhead?
>
> I am remembering an estimate from mid last week that put retpoline at
> replacing
> a 3 clock 'ret' with 30 clocks of eye-bleed co
On Thu, 2018-01-11 at 01:34 +0300, Alexey Dobriyan wrote:
>
> Bisection points to
>
> f3433c1010c6af61c9897f0f0447f81b991feac1 is the first bad commit
> commit f3433c1010c6af61c9897f0f0447f81b991feac1
> Author: David Woodhouse
> Date: Tue Jan 9 14:43:11 2018 +00
On Wed, 2018-01-10 at 10:41 -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Jan 10, 2018 at 03:28:43PM +0100, Paolo Bonzini wrote:
> > On 10/01/2018 15:06, Arjan van de Ven wrote:
> > > On 1/10/2018 5:20 AM, Paolo Bonzini wrote:
> > >> * a simple specification that does "IBRS=1 blocks indirect
> bran
On Mon, 2018-01-08 at 02:42 -0800, Paul Turner wrote:
>
> While the cases above involve the crafting and use of poisoned
> entries. Recall also that one of the initial conditions was that we
> should avoid RSB underflow as some CPUs may try to use other indirect
> predictors when this occurs.
I
On Wed, 2018-01-10 at 09:18 -0600, Tom Lendacky wrote:
>
> Ok, hence my caveat on the underflow in the reply. If it's to eliminate
> userspace addresses, then yes, it needs to be applied for AMD as well.
>
> In that case maybe the comments in arch/x86/entry/entry_{32,64}.S need to
> be updated s
On Wed, 2018-01-10 at 08:23 -0600, Tom Lendacky wrote:
> On 1/10/2018 7:15 AM, Woodhouse, David wrote:
> > On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote:
> >> From: Andi Kleen
> >>
> >> X86_FEATURE_RETPOLINE has been renamed to X86_FEATURE_RETPOLINE_GENER
On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> [This fixes a boot failure in the earlier patches
> so may want to be moved earlier to keep git bisect
> happy]
>
> With the latest tip x86/pti I get oopses when booting
> a 64bit VM in qemu with RETPOLINE/gcc7 and PTI en
On Tue, 2018-01-09 at 18:28 -0800, Andi Kleen wrote:
> From: Andi Kleen
>
> X86_FEATURE_RETPOLINE has been renamed to X86_FEATURE_RETPOLINE_GENERIC.
> Convert the sequences using it.
AMD documentation says they need the RSB fill too, so these should stay
under X86_FEATURE_RETPOLINE I think.
sm
On Tue, 2018-01-09 at 13:36 +0100, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 02:46:32PM +0100, Thomas Gleixner wrote:
> > On Mon, 8 Jan 2018, Josh Poimboeuf wrote:
>
> > > I wonder if an error might be more appropriate than a warning. I
> > > learned from experience that a lot of people don
On Mon, 2018-01-08 at 17:21 -0800, Andi Kleen wrote:
> On Mon, Jan 08, 2018 at 05:16:02PM -0800, Andi Kleen wrote:
> > > If we clear the registers, what the hell are you going to put in the
> > > RSB that helps you?
> >
> > RSB allows you to control chains of gadgets.
>
> I admit the gadget thing
On Mon, 2018-01-08 at 16:15 -0800, Paul Turner wrote:
> On Mon, Jan 8, 2018 at 2:11 PM, Peter Zijlstra wrote:
> > On Mon, Jan 08, 2018 at 12:15:31PM -0800, Andi Kleen wrote:
> >> diff --git a/arch/x86/include/asm/nospec-branch.h
> >> b/arch/x86/include/asm/nospec-branch.h
> >> index b8c8eeacb4be.
On Mon, 2018-01-08 at 15:56 -0800, Linus Torvalds wrote:
> On Mon, Jan 8, 2018 at 3:44 PM, David Woodhouse wrote:
> >
> > To guard against this fill the return buffer with controlled
> > content during context switch. This prevents any underflows.
>
> Ugh. I really dislike this patch. Everything
On Mon, 2018-01-08 at 23:26 +0100, Peter Zijlstra wrote:
>
> > is because that might get interpreted as a "push %rip" and not go on
> > the RSB at all. Hence the 'pause' between each one.
>
> OK, then make the comment say that.
Fixed. I've also shifted the #ifdef CONFIG_RETPOLINE to the call sit
On Mon, 2018-01-08 at 18:42 +0100, Peter Zijlstra wrote:
> On Mon, Jan 08, 2018 at 09:28:12AM -0800, Tim Chen wrote:
> > On 01/08/2018 08:14 AM, Peter Zijlstra wrote:
> > > On Mon, Jan 08, 2018 at 01:47:07PM +0100, Peter Zijlstra wrote:
> > >>> a good suggestion, but we encountered some issues with
On Mon, 2018-01-08 at 11:25 +0100, Thomas Gleixner wrote:
> On Sun, 7 Jan 2018, David Woodhouse wrote:
>
> Cc+ Josh Poimboeuf
>
> Sigh
>
> > From: Andi Kleen
> >
> > objtool's assembler nanny currently cannot deal with the code generated
> > by the retpoline compiler and throws hundreds o
On Mon, 2018-01-08 at 11:08 +0100, Thomas Gleixner wrote:
> I'm dropping these patches until this question is answered.
I've rebased my retpoline tree on top of tip/x86/pti from before those
patches (from my BUG_SPECTRE_Vx patch).
smime.p7s
Description: S/MIME cryptographic signature
On Sun, 2018-01-07 at 23:06 -0600, Josh Poimboeuf wrote:
>
> Here's the use case I had in mind before. With paravirt,
>
> ENABLE_INTERRUPTS(CLBR_NONE)
>
> becomes
>
> push %rax
> call *pv_irq_ops.irq_enable
> pop %rax
>
> and I wanted to apply those instructions with an alternativ
On Sun, 2018-01-07 at 21:01 +0300, Ivan Ivanov wrote:
> Make sure that your patches do not affect AMD CPU,
> because they are unaffected by Meltdown vulnerability
> for which this "30% slowdown Intel patch" is required
These patches *do* affect AMD CPUs, because they address one of the
issues for
On Sat, 2018-01-06 at 21:34 +, Andrew Cooper wrote:
> On 06/01/18 21:23, Thomas Gleixner wrote:
> >
> > On Sat, 6 Jan 2018, Andrew Cooper wrote:
> > >
> > > On 06/01/18 11:49, David Woodhouse wrote:
> > > >
> > > > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> >
On Sat, 2018-01-06 at 21:16 +, Andrew Cooper wrote:
> On 06/01/18 11:49, David Woodhouse wrote:
> > diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> > index 372ba3f..40e6e54 100644
> > --- a/arch/x86/kernel/cpu/common.c
> > +++ b/arch/x86/kernel/cpu/common.c
> > @@ -90
On Fri, 2018-01-05 at 18:12 -0800, Tim Chen wrote:
> On new microcode write, check whether IBRS
> is present by rescanning IBRS feature.
>
> Signed-off-by: Tim Chen
Didn't we also give you a patch which fixed up the error handling on
the microcode reload, when it fails on only one CPU?
smime.p7
On Fri, 2018-01-05 at 18:12 -0800, Tim Chen wrote:
> Tim Chen (8):
> x86/feature: Detect the x86 IBRS feature to control Speculation
> x86/enter: MACROS to set/clear IBRS
> x86/enter: Use IBRS on syscall and interrupts
> x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature
>
On Fri, 2018-01-05 at 22:43 -0800, Tim Chen wrote:
>
> On 01/05/2018 06:12 PM, Tim Chen wrote:
> >
> > Thanks to everyone for the feedback on the initial posting.
> > This is an updated patchset and I hope I've captured all
> > the review comments. I've done a lot of code clean up
> > per everyo
On Fri, 2018-01-05 at 15:50 -0800, Linus Torvalds wrote:
>
> > +
> > +.macro RETPOLINE_CALL reg:req
> > + jmp 1113f
> > +1110: RETPOLINE_JMP \reg
> > +1113: call 1110b
> > +.endm
(Note that RETPOLINE_CALL is purely internal to nospec-branch.h, used
only from the NOSPEC_CALL macro
On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote:
> That said, I honestly like the inline version (the one that is in the
> google paper first) of the retpoline more than the out-of-line one.
> And that one shouldn't have any relocagtion issues, because all the
> offsets are relative.
>
> W
On Fri, 2018-01-05 at 09:28 -0800, Linus Torvalds wrote:
>
> Yes, I would suggest against expecting altinstructions to have
> relocation information. They are generated in a different place, so..
>
> That said, I honestly like the inline version (the one that is in the
> google paper first) of th
On Fri, 2018-01-05 at 17:45 +0100, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 04:41:46PM +0000, Woodhouse, David wrote:
> > Nope, alternatives are broken. Only a jmp as the *first* opcode of
> > altinstr gets handled by recompute_jump(), while any subsequent insn is
> >
On Fri, 2018-01-05 at 13:56 +, Woodhouse, David wrote:
>
> At some point during this whole painful mess, I had come to the
> conclusion that having relocations in altinstr didn't work, and that's
> why I had X86_xx_NO_RETPOLINE instead of X86_xx_RETPOLINE. I now think
On Fri, 2018-01-05 at 13:54 +0100, Thomas Gleixner wrote:
> On Thu, 4 Jan 2018, David Woodhouse wrote:
> > diff --git a/arch/x86/include/asm/cpufeatures.h
> > b/arch/x86/include/asm/cpufeatures.h
> > index 07cdd1715705..900fa7016d3f 100644
> > --- a/arch/x86/include/asm/cpufeatures.h
> > +++ b/arc
On Fri, 2018-01-05 at 15:27 +0100, Thomas Gleixner wrote:
> Subject: x86/pti: Rename BUG_CPU_INSECURE to BUG_CPU_MELTDOWN
> From: Thomas Gleixner
> Date: Fri, 05 Jan 2018 15:05:27 +0100
>
> Use the name associated with the particular attack which needs page
> table
> isolation for mitigation.
>
On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote:
> On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote:
> >
> > From: David Woodhouse
> >
> > We are impervious to the indirect branch prediction attack with
> > retpoline
> > but firmware won't be, so we still need to set IBRS to protect
> >
On Thu, 2018-01-04 at 07:53 -0800, Andi Kleen wrote:
>
> I remove that because what you're testing for doesn't exist in the
> tree yet.
>
> Yes it can be added later.
>
> Right now we just want a basic static version to work reliably.
But it doesn't. You can't protect VMs from each other, or u
On Thu, 2018-01-04 at 14:51 +, Andrew Cooper wrote:
>
> > * never turn off indirect branch prediction, but use a branch prediction
> > barrier on every mode switch (needed for current AMD microcode)
>
> Where have you got this idea from? Using IBPB on every mode switch
> would be an insane o
On Thu, 2018-01-04 at 16:02 +0100, Juergen Gross wrote:
> On 04/01/18 15:37, David Woodhouse wrote:
> > Convert pvops invocations to use non-speculative call sequences, when
> > CONFIG_RETPOLINE is enabled.
> >
> > There is scope for future optimisation here — once the pvops methods are
> > actual
On Thu, 2018-01-04 at 15:20 +0100, Paolo Bonzini wrote:
> On 04/01/2018 12:47, Woodhouse, David wrote:
> >
> > On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote:
> > >
> > >
> > > >
> > > > No, really. The full mitigation wi
On Thu, 2018-01-04 at 06:46 -0800, Dave Hansen wrote:
> On 01/04/2018 06:37 AM, David Woodhouse wrote:
> > KPTI complicates this a little; the one in entry_SYSCALL_64_trampoline
> > can't just jump to the thunk because the thunk isn't mapped. So it gets
> > its own copy of the thunk, inline.
>
> T
On Thu, 2018-01-04 at 12:42 +0100, Pavel Machek wrote:
>
> > No, really. The full mitigation with the microcode update and IBRS
> > support is *slow*. Horribly slow.
>
> What is IBRS? Invalidate BRanch prediction bufferS?
That isn't the precise acronym, but yes.
The branch predictor flush that,
On Thu, 2018-01-04 at 10:48 +0100, Greg Kroah-Hartman wrote:
>
> Nice, thanks for the link and the write up. There is also a patch for
> gcc floating around somewhere, does anyone have the link for that?
http://git.infradead.org/users/dwmw2/gcc-retpoline.git/shortlog/refs/heads/gcc-7_2_0-retpoli
On Thu, 2018-01-04 at 01:10 -0800, Paul Turner wrote:
> Apologies for the discombobulation around today's disclosure. Obviously the
> original goal was to communicate this a little more coherently, but the
> unscheduled advances in the disclosure disrupted the efforts to pull this
> together more
On Wed, 2018-01-03 at 16:40 -0800, Andi Kleen wrote:
> >
> > So you say, that we finally need a perl interpreter in the kernel
> > to do
> > alternative patching?
> I don't think perl or objtool makes sense. That would be just
> incredibly
> fragile because compilers can reorder and mix code.
>
On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote:
> On 04/01/2018 02:59, Alan Cox wrote:
> >> But then, exactly because the retpoline approach adds quite some cruft
> >> and leaves something to be desired, why even bother?
> >
> > Performance
>
> Dunno. If I care about mitigating this threa
On Thu, 2016-05-05 at 16:45 +0900, Masahiro Yamada wrote:
>
> This commit fixes arg-check to compare two strings as a whole.
> $(strip ...) is important because we want to ignore the difference
> that comes from white-spaces.
Do we?
I can construct a hypothetical situation in which whitespace di
On Thu, 2015-11-12 at 09:36 +, David Howells wrote:
> If it works, it emit a key ID; if it fails, it should give a bad
> message error.
In this sentence, failure is good, yes? This is a malformed key so we
*expect* the failure?
--
David WoodhouseOpen Source Techno
On Sat, 2015-10-17 at 08:18 +0300, Dan Carpenter wrote:
> There is an extra semi-colon on this if statement so we always break
> on the first iteration.
Heh, it worked in my testing with only one registered device :)
Oops; thanks :)
--
David WoodhouseOpen Source Tec
On Tue, 2015-09-29 at 18:09 -0700, Ashutosh Dixit wrote:
> From: Sudeep Dutt
>
> iova is a library which can be built without IOMMU_SUPPORT
>
> Signed-off-by: Sudeep Dutt
The first three of these patches are in 4.3-rc4 already. Apologies for
the delay in pushing them out.
This one looks sane
On Thu, 2015-05-21 at 10:02 -0700, gre...@linuxfoundation.org wrote:
>
> Again, why have a detached signature and not just part of the firmware
> blob? The device needs to be caring about this, not the kernel.
>
> Do other operating systems have this type of "feature"?
Yes. Windows effectively
On Thu, 2015-05-21 at 12:22 -0400, Mimi Zohar wrote:
>
> That's great! What format do you expect the detached signatures to
> be?
> Where will they reside?
Well, it kind of depends how things stand when the dust settles, but I
suppose the current plan would be to have .p7s files next to the
bin
On Thu, 2015-05-21 at 08:45 -0700, Greg Kroah-Hartman wrote:
> On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> > Signatures don't provide any guarantees as to code quality or
> > correctness. They do provide file integrity and provenance. In
> > addition to the license and a Signed
On Tue, 2015-05-19 at 07:45 -0400, Mimi Zohar wrote:
>
> /bin/sh: line 1: 22771 Segmentation fault (core dumped)
> scripts/sign-file "sha256" "pkcs11:manufacturer=piv_II;id=%01"
> ./signing_key.x509 /lib/modules/4.1.0-rc1
> -test+/kernel/net/ipv6/netfilter/ip6table_filter.ko
> /home/zohar/s
On Mon, 2015-05-18 at 21:29 -0400, Mimi Zohar wrote:
> On Fri, 2015-05-15 at 17:52 +0100, David Woodhouse wrote:
> > Signed-off-by: David Woodhouse
>
> I assume the patch descriptions will be added before being upstreamed.
This patch aborts modules_install when signing fails :)
> With this pa
On Thu, 2014-08-21 at 07:35 +0930, Rusty Russell wrote:
>
> Above this:
> if (!mk->mp) {
> num = 0;
> attrs = NULL;
> } else {
> num = mk->mp->num;
> attrs = mk->mp->grp.attrs;
> }
>
> So, attrs is just a temp
On Thu, 2014-08-21 at 06:19 +0930, Rusty Russell wrote:
> Arjun Sreedharan writes:
> > Do not leak memory when attrs is non NULL and
> > krealloc() fails. Without temporary variable,
> > reference to it is lost.
> >
> > Signed-off-by: Arjun Sreedharan
>
> ...
>
> > }
> > - /* Despite look
On Wed, 2014-04-16 at 15:37 +0200, j...@8bytes.org wrote:
> Hey David,
>
> On Mon, Apr 14, 2014 at 05:03:51PM +, Woodhouse, David wrote:
> > Jiang, if you can then let me have a copy with a signed-off-by I'll
> > shepherd it upstream along with your other pa
On Mon, 2014-04-14 at 09:47 -0700, Davidlohr Bueso wrote:
> On Mon, 2014-04-14 at 09:44 -0700, Davidlohr Bueso wrote:
> > On Tue, 2014-04-15 at 00:19 +0800, Jiang Liu wrote:
> > > Hi Davidlohr,
> > > Thanks for providing the DMAR table. According to the DMAR
> > > table, one bug in the iommu driv
On Sun, 2014-04-13 at 22:01 +0200, Stefani Seibold wrote:
> Rebooting my kernel vanilla kernel 3.14 will fail with tons of kernel
> log messages:
>
> [0.262754] IOMMU: Setting identity map for device :00:1a.0
> [0x7c45f000 - 0x7c46bfff]
> [0.262780] IOMMU: Setting identity map for dev
On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
> Attaching a dmesg from one of the kernels that boots. It doesn't appear
> to have much of the related information... is there any debug config
> option I can enable that might give you more data?
I'd like the contents of /sys/firmware/acp
On Thu, 2014-04-10 at 09:19 -0700, Davidlohr Bueso wrote:
> > > > > >> > > > > dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr
> > > > > >> > > > > 7f61e000
> >
> > That "Present bit in context entry is clear" fault means that we have
> > not set up *any* mappings for this PCI device… o
On Thu, 2014-04-10 at 09:14 -0600, Bjorn Helgaas wrote:
> > Thus, my first guess would be that we are quite happily setting up the
> > requested DMA maps on the *wrong* IOMMU, and then taking faults when the
> > device actually tries to do DMA.
> >
> I like the "wrong IOMMU (or no IOMMU at all)" th
On Thu, 2014-04-10 at 09:15 +0200, Joerg Roedel wrote:
> [+ David, VT-d maintainer ]
>
> Jiang, David, can you please have a look into this issue?
>
> > > >> > > > > DMAR:[fault reason 02] Present bit in context entry is clear
> > > >> > > > > dmar: DRHD: handling fault status reg 602
> > > >> >
On Thu, 2014-01-30 at 10:09 +0100, Ingo Molnar wrote:
>
> This broke the build though:
>
> arch/x86/boot/compressed/../cpuflags.c: Assembler messages:
> arch/x86/boot/compressed/../cpuflags.c:35: Error: invalid instruction
> suffix for `pushf'
Ah, that only happens with CONFIG_RANDOMIZE_BASE, so
On Tue, 2014-01-14 at 20:14 +0100, Jan-Simon Möller wrote:
> Hi David,
>
> what version of clang did you use btw ?
This is LLVM HEAD + extra patches at git://,
http://git.infradead.org/users/dwmw2/llvm.git and the following patch to
clang HEAD:
diff --git a/include/clang/Driver/Options.td b/incl
On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>
> There are two problems with this:
>
> 1) The kernel will only boot if it's signed with a key in db, not a key
> in MOK.
> 2) grub will read the kernel, but the kernel will have to read the
> initramfs using EFI calls. That means your
1 - 100 of 124 matches
Mail list logo
