/intel_mid_pci.c:303:2: error: implicit declaration of function
‘acpi_noirq_set’; did you mean ‘acpi_irq_get’?
[-Werror=implicit-function-declaration]
acpi_noirq_set();
Signed-off-by: Randy Dunlap
Cc: Jacob Pan
Cc: Len Brown
Cc: Bjorn Helgaas
Cc: Jesse Barnes
Cc: Arjan van de Ven
Cc: linux
On 2/20/2019 7:35 AM, David Laight wrote:
From: Sent: 16 February 2019 12:56
To: Li, Aubrey
...
The above experiment just confirms what I said: The numbers are inaccurate
and potentially misleading to a large extent when the AVX using task is not
scheduled out for a longer time.
Not only tha
On 1/14/2019 5:06 AM, Jiri Kosina wrote:
On Mon, 14 Jan 2019, Pavel Machek wrote:
Frankly I'd not call it Meltdown, as it works only on data in the cache,
so the defense is completely different. Seems more like a l1tf
:-).
Meltdown on x86 also seems to work only for data in L1D, but the pipel
On 12/31/2018 8:22 AM, Ben Greear wrote:
On 12/21/2018 05:17 PM, Tim Chen wrote:
On 12/21/18 1:59 PM, Ben Greear wrote:
On 12/21/18 9:44 AM, Tim Chen wrote:
Thomas,
Andi and I have made an update to our draft of the Spectre admin guide.
We may be out on Christmas vacation for a while. But
On 12/17/2018 3:29 AM, Paul E. McKenney wrote:
As does this sort of report on a line that contains simple integer
arithmetic and boolean operations.;-)
Any chance of a bisection?
btw this looks like something caused a stack overflow and thus all the
weirdness that then happens
On 12/11/2018 3:46 PM, Li, Aubrey wrote:
On 2018/12/12 1:18, Dave Hansen wrote:
On 12/10/18 4:24 PM, Aubrey Li wrote:
The tracking turns on the usage flag at the next context switch of
the task, but requires 3 consecutive context switches with no usage
to clear it. This decay is required becaus
On processors with enhanced IBRS support, we recommend setting IBRS to 1
and left set.
Then why doesn't CPU with EIBRS support acutally *default* to '1', with
opt-out possibility for OS?
(slightly longer answer)
you can pretty much assume that on these CPUs, IBRS doesn't actually do anything
On processors with enhanced IBRS support, we recommend setting IBRS to 1
and left set.
Then why doesn't CPU with EIBRS support acutally *default* to '1', with
opt-out possibility for OS?
the BIOSes could indeed get this set up this way.
do you want to trust the bios to get it right?
On 11/21/2018 2:53 PM, Borislav Petkov wrote:
On Wed, Nov 21, 2018 at 11:48:41PM +0100, Thomas Gleixner wrote:
Btw, I really do not like the app2app wording. I'd rather go for usr2usr,
but that's kinda horrible as well. But then, all of this is horrible.
Any better ideas?
It needs to have "ta
On 11/20/2018 11:27 PM, Jiri Kosina wrote:
On Mon, 19 Nov 2018, Arjan van de Ven wrote:
In the documentation, AMD officially recommends against this by default,
and I can speak for Intel that our position is that as well: this really
must not be on by default.
Thanks for pointing to the AMD
On 11/19/2018 6:00 AM, Linus Torvalds wrote:
On Sun, Nov 18, 2018 at 1:49 PM Jiri Kosina wrote:
So why do that STIBP slow-down by default when the people who *really*
care already disabled SMT?
BTW for them, there is no impact at all.
Right. People who really care about security and are a
I'd prefer the kernel to do such clustering...
I think that is a next step.
Also, while the kernel can do this at a best effort basis, it cannot
take into account things the kernel doesn't know about, like high
priority job peak load etc.., things a job scheduler would know.
Then again, a j
On 7/13/2018 12:19 PM, patrickg wrote:
This RFC patch is intended to allow bypass CPUID, MSR and QuickPIT calibration
methods should the user desire to.
The current ordering in ML x86 tsc is to calibrate in the order listed above;
returning whenever there's a successful calibration. However t
> To add a bit more to this, Intel just updated their
> IA32_ARCH_CAPABILITIES_MSR
> to have a new bit to sample to figure out whether you need IBRS or not
> during runtime.
actually we updated the document when you need RSB stuffing.
based on the request of various folks here on LKML.
> > In the past the only guidance was to not load microcode at the same time to
> the
> > thread siblings of a core. We now have new guidance that the sibling must be
> > spinning and not doing other things that can introduce instability around
> loading
> > microcode.
>
> Document that properly
> > I meant software wise. You're not going to live migrate from xen to
> > kvm or backwards. or between very radically different versions of the
> > kvm stack.
>
> Forwards migration to a radically newer version certainly happens. So
> when the source hypervisor was too old to tell the VM about
tends to only work between HV's that are relatively
> > homogeneous, that's nothing new...
>
> No Arjan, this is just wrong. Well, I suppose it's right in the present
> tense with the IBRS mess on Skylake, but it's _not_ been true until last
> year.
I meant software wise.
> > On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox
> wrote:
> > >
> > > In theory there's nothing stopping a guest getting a 'you are about to
> > > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
> > > removed.
> >
> > I'm not convinced we handle the case of hotplug CPU's with
> On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
>
> > the guest is not the problem; guests obviously will already honor if
> > Enhanced
> > IBRS is enumerated. The problem is mixed migration pools where the
> hypervisor
> > may need to
>
> >>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the
> >>> (now emulated) MSR on every kernel entry/exit, that's *still* going to
> >>> be a metric shitload faster than what it *thought* it was doing.
>
> Is there any indication/log to the admin that VM doesn't know about
On 2/16/2018 11:43 AM, Linus Torvalds wrote:
On Fri, Feb 16, 2018 at 11:38 AM, Linus Torvalds
wrote:
Of course, your patch still doesn't allow for "we claim to be skylake
for various other independent reasons, but the RSB issue is fixed".
.. maybe nobody ever has a reason to do that, though?
On 2/14/2018 11:29 AM, Andy Shevchenko wrote:
On Mon, Feb 12, 2018 at 9:50 PM, Srinivas Pandruvada
wrote:
On systems supporting HWP (Hardware P-States) mode, we expected to
enumerate core priority via ACPI-CPPC tables. Unfortunately deployment of
TURBO 3.0 didn't use this method to show core pr
So, any hints on what you think should be the correct fix here?
the patch sure looks correct to me, it now has a nice table for CPU IDs
including all of AMD (and soon hopefully the existing Intel ones that are not
exposed to meltdown)
> > Raw diff between the mainline blacklist and the bulletin looks like:
> > @@ -1,5 +1,6 @@
> > { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 },
> > { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b },
> > +{ INTEL_FAM6_BROADWELL_X,0x01, 0x0b23 },
> > { INTEL_FAM6_BROADWELL_X,0x01,
> On Wed, Jan 31, 2018 at 8:55 AM, Paolo Bonzini wrote:
>
> > In fact this MSR can even be passed down unconditionally, since it needs
> > no save/restore and has no ill performance effect on the sibling
> > hyperthread.
>
> I'm a bit surprised to hear that IBPB has no ill performance impact on
On 1/31/2018 2:15 AM, Thomas Gleixner wrote:
Good luck with making all that work.
on the Intel side we're checking what we can do that works and doesn't break
things right now; hopefully we just end up with a bit in the arch capabilities
MSR for "you should do RSB stuffing" and then the HV's c
> > short term there was some extremely rudimentary static analysis done.
> > clearly
> > that has extreme limitations both in insane rate of false positives, and
> > missing
> > cases.
>
> What was the output roughly, how many suspect places that need
> array_idx_nospec()
> handling: a few, a f
> > Anyway, I do think the patches I've seen so far are ok, and the real
> > reason I'm writing this email is actually more about future patches:
> > do we have a good handle on where these array index sanitations will
> > be needed?
the obvious cases are currently obviously being discussed.
but
On 1/30/2018 5:11 AM, Borislav Petkov wrote:
On Tue, Jan 30, 2018 at 01:57:21PM +0100, Thomas Gleixner wrote:
So much for the theory. That's not going to work. If the boot cpu has the
feature then the alternatives will have been applied. So even if the flag
mismatch can be observed when a second
On 1/29/2018 7:32 PM, Linus Torvalds wrote:
On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven wrote:
the most simple solution is that we set the internal feature bit in Linux
to turn on the "stuff the RSB" workaround is we're on a SKL *or* as a guest
in a VM.
That so
On 1/29/2018 4:23 PM, Linus Torvalds wrote:
Why do you even _care_ about the guest, and how it acts wrt Skylake?
What you should care about is not so much the guests (which do their
own thing) but protect guests from each other, no?
the most simple solution is that we set the internal feature
On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
The question is how the hypervisor could tell that to the guest.
If Intel doesn't give us a CPUID bit that can be used to tell
that retpolines are enough, maybe we should use a hypervisor
CPUID bit for that?
the objective is to have retpoline be saf
> On 29/01/2018 01:58, KarimAllah Ahmed wrote:
> > Add direct access to MSR_IA32_SPEC_CTRL for guests. Future intel processors
> > will use this MSR to indicate RDCL_NO (bit 0) and IBRS_ALL (bit 1).
>
> This has to be customizable per-VM (similar to the patches Amazon posted
> a while ago for UCOD
>
> On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
> >
> > Do you mean that the host would intercept the guest WRMSR and do
> > WRMSR itself? I would suggest that doing so is inconsistent with the
> > docs. As specified, doing WRMSR to write 1 to IBRS does *not*
> > protect the guest.
> > you asked before and even before you sent the email I confirmed to
> > you that the document is correct
> >
> > I'm not sure what the point is to then question that again 15 minutes
> > later other than creating more noise.
>
> Apologies, I hadn't seen the comment on IRC.
>
> Sometimes the do
> On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> > On 1/26/2018 10:11 AM, David Woodhouse wrote:
> > >
> > > I am *actively* ignoring Skylake right now. This is about per-SKL
> > > userspace even with SMEP, because we think Intel's document l
On 1/26/2018 10:11 AM, David Woodhouse wrote:
I am *actively* ignoring Skylake right now. This is about per-SKL
userspace even with SMEP, because we think Intel's document lies to us.
if you think we lie to you then I think we're done with the conversation?
Please tell us then what you deploy
On 1/26/2018 7:27 AM, Dave Hansen wrote:
On 01/26/2018 04:14 AM, Yves-Alexis Perez wrote:
I know we'll still be able to manually enable PTI with a command line option,
but it's also a hardening feature which has the nice side effect of emulating
SMEP on CPU which don't support it (e.g the Atom b
k, Asit K
> ; rkrc...@redhat.com; karah...@amazon.de;
> h...@zytor.com; mi...@redhat.com; Nakajima, Jun
> ; x...@kernel.org; Raj, Ashok ;
> Van De Ven, Arjan ; tim.c.c...@linux.intel.com;
> pbonz...@redhat.com; a...@linux.intel.com; linux-kernel@vger.kernel.org;
> dw...@in
This patch tries to address the case when we do switch to init_mm and back.
Do you still have objections to the approach in this patch
to save the last active mm before switching to init_mm?
how do you know the last active mm did not go away and started a new process
with new content?
(other t
The idea is simple, do what we do for virt. Don't send IPI's to CPUs
that don't need them (in virt's case because the vCPU isn't running, in
our case because we're not in fact running a user process), but mark the
CPU as having needed a TLB flush.
I am really uncomfortable with that idea.
You re
On 1/25/2018 5:50 AM, Peter Zijlstra wrote:
On Thu, Jan 25, 2018 at 05:21:30AM -0800, Arjan van de Ven wrote:
This means that 'A -> idle -> A' should never pass through switch_mm to
begin with.
Please clarify how you think it does.
the idle code does leave_mm() to avoid ha
This means that 'A -> idle -> A' should never pass through switch_mm to
begin with.
Please clarify how you think it does.
the idle code does leave_mm() to avoid having to IPI CPUs in deep sleep states
for a tlb flush.
(trust me, that you really want, sequentially IPI's a pile of cores in a d
why I kind of hate the whitelist, but
Arjan is very insistent...)
Ick, no, whitelists are a pain for everyone involved. Don't do that
unless it is absolutely the only way it will ever work.
Arjan, why do you think this can only be done as a whitelist?
I suggested a minimum version list for
> > It is a reasonable approach. Let a process who needs max security
> > opt in with disabled dumpable. It can have a flush with IBPB clear before
> > starting to run, and have STIBP set while running.
> >
>
> Do we maybe want a separate opt in? I can easily imagine things like
> web browsers
On 1/21/2018 8:21 AM, Ingo Molnar wrote:
So if it's only about the scheduler barrier, what cycle cost are we talking
about
here?
in the order of 5000 to 1 cycles.
(depends a bit on the cpu generation but this range is a reasonable
approximation)
Because putting something like this
: Hou Tao ; aarca...@redhat.com; linux-
> ker...@vger.kernel.org; Van De Ven, Arjan
> Cc: mi...@redhat.com; Thomas Gleixner ;
> a...@linux.intel.com; dave.han...@linux.intel.com; pet...@infradead.org;
> qiuxi...@huawei.com; wangkefeng.w...@huawei.com
> Subject: Re: [RH72 Spectre] ibpb_
> Enabling IBRS does not prevent software from controlling the predicted
> targets of indirect branches of unrelated software executed later at
> the same predictor mode (for example, between two different user
> applications, or two different virtual machines). Such isolation can
> be ensured thro
Does anybody have any other ideas?
the only other weird case that comes to mind; what happens if there's a line
dirty in the caches,
but the memory is now mapped uncached. (Which could happen if kexec does muck
with MTRRs, CR0 or other similar
things in weird ways)... not sure what happens in
Does anybody have any other ideas?
wbinvd is thankfully not common, but also not rare (MTRR setup and a bunch of
other cases)
and in some other operating systems it happens even more than on Linux.. it's
generally not totally broken like this.
I can only imagine a machine check case where a
> I just sent a v3 that changes the VERMAGIC only, based on Greg's
> earlier feedback.
>
> It has the drawbacks that it:
> - refuses loading instead of warns
> - doesn't stop refusing when the feature is runtime disabled
>
> But it's much simpler, just a few lines of ifdef.
I think simple is goo
> Having firmware refill the RSB only makes a difference if you are on
> Skylake+ were RSB underflows are bad, and you're not using IBRS to
> protect your indirect predictions.
... and before that you don't need it.
This would means that userspace would see return predictions based
on the values the kernel 'stuffed' into the RSB to fill it.
Potentially this leaks a kernel address to userspace.
KASLR pretty much died in May this year to be honest with the KAISER paper (if
not before then)
also with KPTI
> > For modules it is checked at compile time, however it cannot
> > check assembler or other non compiled objects used in the module link.
>
> It is not unlikely that most of a module's code is released as a
> binary 'blob', with only the part that needs to match the kernel ABI
> compiled on the
> > When the a module hasn't been compiled with a retpoline
> > aware compiler, print a warning and set a taint flag.
>
> Isn't that caught by the "build with a different compiler/version" check
> that we have? Or used to have? If not, can't we just make it into that
> type of check to catch thi
> > The RSB filling macro is applicable to AMD, and, if software is unable to
> > verify that lfence is serializing on AMD (possible when running under a
> > hypervisor), the generic retpoline support will be used and, so, is also
> > applicable to AMD. Change the use of pause to lfence.
> >
> > S
> > We were also worried about the indirect calls that are part of the
> > paravirt interfaces when retpolines are not in place.
> >
>
> How could those possibly be any worse than any other indirect call in
> the kernel?
they're worse if they happen before you write the MSR that then protects th
> On SKL+ retpoline is mostly there, but has a few dinky holes in and it
> _might_ make sense to use IBRS.
>
> But I feel it needs explaining what the exact holes are (pjt and dwmw2
> had a fair enumeration IIRC) such that people can judge the risk.
you are correct to need and want this.
the pro
pendent and slow and whatever and that IBRS_ATT will be in
> > future CPUs. So get your act together and tell a clear YES or NO.
>
> Other comments/code from Tim Chen, and Dave Hansen and most important
> the ibrs_enabled 2 description and implementation on lkml, makes me
> st
On 1/10/2018 5:20 AM, Paolo Bonzini wrote:
* a simple specification that does "IBRS=1 blocks indirect branch
prediction altogether" would actually satisfy the specification just as
well, and it would be nice to know if that's what the processor actually
does.
it doesn't exactly, not for all.
s
> ibrs_enabled 2:
>
> sets IBRS always in host
this is not secure
> This matches the semantics described here by Tim patchset on lkml:
>
> https://marc.info/?l=linux-kernel&m=151520606320646
I will talk to Tim, it's not right.
> I can tell in practice it works as I described in all microco
> So here is the simple list of questions all to be answered with YES or
> NO. I don't want to see any of the 'but, though ...'. We all know by now
> that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
> future CPUs. So get your act together and tell a clear YES or NO.
I wil
> Andrea, what you're saying is directly contradicting what I've heard
> from Intel.
>
> The documentation already distinguishes between IBRS on current
> hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
> on current hardware is a set-and-forget option and completely disab
> On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote:
> > IBRS is like a barrier. You must write it between the 'problematic'
> > loading of the branch targets, and the kernel code which might be
> > affected.
> >
> > You cannot, on current hardware, merely set it once and forget abo
> 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
On 1/9/2018 8:17 AM, Paolo Bonzini wrote:
On 09/01/2018 16:19, Arjan van de Ven wrote:
On 1/9/2018 7:00 AM, Liran Alon wrote:
- ar...@linux.intel.com wrote:
On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
The above ("IBRS simply disables the indirect branch predictor") was my
I'm sorry I'm not familiar with your L0/L1/L2 terminology
(maybe it's before coffee has had time to permeate the brain)
These are standard terminology for guest levels:
L0 == hypervisor that runs on bare-metal
L1 == hypervisor that runs as L0 guest.
L2 == software that runs as L1 guest.
(We ar
ors. Let's ask Arjan who might have more
information about it, and hope he actually can disclose it...
IBRS will ensure that, when set after the ring transition, no earlier
branch prediction data is used for indirect branches while IBRS is
set
Consider the following scenario:
1. L1 runs wit
ause honestly a microcode update is unlikely to do much
more than an old-fashioned chicken bit. Maybe on Skylake it does
though, since the performance characteristics of IBRS are so different
from previous processors. Let's ask Arjan who might have more
information about it, and hope he actu
> > + if ((!c->cpu_index) && (boot_cpu_has(X86_FEATURE_SPEC_CTRL))) {
>
> We should test X86_BUG_SPECTRE_V1 here too before default enabling this,
> no?
we shouldn't default enable this.
> > it's a mistake though... retpoline is what people should be using
> > ... and only in super exception cases should IBRS even be considered
>
> Like on certain Skylake and Broadwell where using the retpoline won't suffice?
skylake is a bit more complex but that was discussed in earlier e
> I agree. But this is what customers are told to inspect to see if they
> are impacted. And if in the future versions this goes away or such - they
> will freak out and cause needless escalations.
it's a mistake though... retpoline is what people should be using
... and only in super except
It sounds like Coverity was used to produce these patches? If so, is
there a plan to have smatch (hey Dan) or other open source static
analysis tool be possibly enhanced to do a similar type of work?
I'd love for that to happen; the tricky part is being able to have even a
sort of sensible conce
> >> .macro DISABLE_IBRS
> >> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> >> + testl $1, dynamic_ibrs
> > On every system call we end up hammering on this 'dynamic_ibrs'
> > variable. And it looks like it can be flipped via the IPI mechanism.
> >
> > Would it make sense for this
> On Fri, Jan 05, 2018 at 04:37:30PM +, David Woodhouse wrote:
> > You are completely ignoring pre-Skylake here.
> >
> > On pre-Skylake, retpoline is perfectly sufficient and it's a *lot*
> > faster than the IBRS option which is almost prohibitively slow.
> >
> > We didn't do it just for fun. A
>
> Doing a huge amount of work with reptoline and then you find SMM is
> called reproducibly somehow and a new PoC could exist for it, not fun.
retpoline we want for broadwell and earlier anyway..
I'm sorry but your whole statement reeks a little bit of "perfect is the enemy
of good"
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, January 05, 2018 3:32 AM
> To: Van De Ven, Arjan ; Linus Torvalds
> ; David Woodhouse
> Cc: Tim Chen ; Thomas Gleixner
> ; Andy Lutomir
> > So long as the underlying binary satisfies the precondition that it
> > will not underflow its own RSB.
> >
> > Then we if we subsequently guarantee never to _reduce_ the number of
> > entries in its RSB at any point remote to its own execution, then the
> > precondition is preserved and underf
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse
> wrote:
> >
> > On Skylake the target for a 'ret' instruction may also come from the
> > BTB. So if you ever let the RSB (which remembers where the 'call's came
> > from get empty, you end up vulnerable.
>
> That sounds like it could cause mispr
On 7/20/2017 1:11 AM, Thomas Gleixner wrote:
On Thu, 20 Jul 2017, Li, Aubrey wrote:
Don't get me wrong, even if a fast path is acceptable, we still need to
figure out if the coming idle is short and when to switch. I'm just worried
about if irq timings is not an ideal statistics, we have to skip
On 7/20/2017 5:50 AM, Paul E. McKenney wrote:
To make this work reasonably, you would also need some way to check for
the case where the prediction idle time is short but the real idle time
is very long.
so the case where you predict very short but is actually "indefinite", the real
solution li
On 7/18/2017 9:36 AM, Peter Zijlstra wrote:
On Tue, Jul 18, 2017 at 08:29:40AM -0700, Arjan van de Ven wrote:
the most obvious way to do this (for me, maybe I'm naive) is to add another
C state, lets call it "C1-lite" with its own thresholds and power levels etc,
and just let
On 7/18/2017 8:20 AM, Paul E. McKenney wrote:
3.2) how to determine if the idle is short or long. My current proposal is to
use a tunable value via /sys, while Peter prefers an auto-adjust mechanism. I
didn't get the details of an auto-adjust mechanism yet
the most obvious way to do this (for
On 7/17/2017 12:53 PM, Thomas Gleixner wrote:
On Mon, 17 Jul 2017, Arjan van de Ven wrote:
On 7/17/2017 12:23 PM, Peter Zijlstra wrote:
Of course, this all assumes a Gaussian distribution to begin with, if we
get bimodal (or worse) distributions we can still get it wrong. To fix
that, we&#
On 7/17/2017 12:46 PM, Thomas Gleixner wrote:
On Mon, 17 Jul 2017, Arjan van de Ven wrote:
On 7/17/2017 12:23 PM, Peter Zijlstra wrote:
Now I think the problem is that the current predictor goes for an
average idle duration. This means that we, on average, get it wrong 50%
of the time. For
On 7/17/2017 12:23 PM, Peter Zijlstra wrote:
Of course, this all assumes a Gaussian distribution to begin with, if we
get bimodal (or worse) distributions we can still get it wrong. To fix
that, we'd need to do something better than what we currently have.
fwiw some time ago I made a chart for
On 7/17/2017 12:23 PM, Peter Zijlstra wrote:
Now I think the problem is that the current predictor goes for an
average idle duration. This means that we, on average, get it wrong 50%
of the time. For performance that's bad.
that's not really what it does; it looks at next tick
and then discount
On 7/14/2017 8:38 AM, Peter Zijlstra wrote:
No, that's wrong. We want to fix the normal C state selection process to
pick the right C state.
The fast-idle criteria could cut off a whole bunch of available C
states. We need to understand why our current C state pick is wrong and
amend the algorit
On 5/27/2017 9:56 AM, Andy Lutomirski wrote:
On Sat, May 27, 2017 at 9:00 AM, Andy Lutomirski wrote:
On Sat, May 27, 2017 at 6:31 AM, kernel test robot
wrote:
FYI, we noticed the following commit:
commit: e2a7dcce31f10bd7471b4245a6d1f2de344e7adf ("x86/mm: Rework lazy TLB to track
the actua
On 5/14/2017 11:27 AM, Thomas Gleixner wrote:
looks good .. ack
On 5/4/2017 6:32 AM, Daniel Micay wrote:
The stack canary is an unsigned long and should be fully initialized to
random data rather than only 32 bits of random data.
that makes sense to me... ack
On 3/22/2017 12:29 PM, Kees Cook wrote:
When performing notifier function pointer sanity checking, allow
CONFIG_BUG_ON_DATA_CORRUPTION to upgrade from a WARN to a BUG.
Additionally enables CONFIG_DEBUG_NOTIFIERS when selecting
CONFIG_BUG_ON_DATA_CORRUPTION.
Any feedback on this change? By defa
On 3/21/2017 8:14 AM, Peter Zijlstra wrote:
For self-documentation purposes, maybe use a define for the length of
the ud0 instruction?
#define TWO 2
;-)
some things make sense as a define, others don't
(adding a comment, maybe)
On 3/9/2017 9:48 AM, Julian Brost wrote:
I'm note entirely sure whether it's actually the kernel or HP to blame,
but for now, hp-health is completely broken on 4.9 (probably on
everything starting from 4.6), so this patch should be reviewed again.
it looks like another kernel driver is doing a
On 2/23/2017 5:28 AM, Peter Zijlstra wrote:
By using "UD0" for WARNs we remove the function call and its possible
__FILE__ and __LINE__ immediate arguments from the instruction stream.
Total image size will not change much, what we win in the instruction
stream we'll loose because of the __bug_
On 1/5/2017 9:54 AM, Thomas Garnier wrote:
That's my goal too. I started by doing a RO remap and got couple
problems with hibernation. I can try again for the next iteration or
delay it for another patch. I also need to look at KVM GDT usage, I am
not familiar with it yet.
don't we write to t
On 1/5/2017 8:40 AM, Thomas Garnier wrote:
Well, it happens only when KASLR memory randomization is enabled. Do
you think it should have a separate config option?
no I would want it a runtime option "sgdt from ring 3" is going away
with UMIP (and is already possibly gone in virtual machines
On 1/5/2017 7:43 AM, Rik van Riel wrote:
On Thu, 2017-01-05 at 23:29 +0800, Alex Shi wrote:
The obsolete commit 71abbbf85 want to introduce a dynamic cstates,
but it was removed for long time. Just left the nonsense deeper
cstate
checking.
Since all target_residency and exit_latency are going l
On 1/5/2017 12:11 AM, Ingo Molnar wrote:
* Thomas Garnier wrote:
Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other
> Ok,
>
> I actually tested boot time with my patch and didn't see a difference
> (so I guess our first attempt to send messages usually succeeds) but if
> we're concearned about less-than-a-second boot time we'd rather keep the
> microseonds delay for first several attempts. I'll do v2.
of cours
1 - 100 of 1885 matches
Mail list logo
