On 01/05/2018 04:27 AM, Dr. David Alan Gilbert wrote:
>>> Patches for 1-3 are out there and 4 is pretty straightforward. Doing a
>>> arch_prctl() is still straightforward, but will be a much more niche
>>> thing than any of the other choices. Plus, with a user interface, we
>>> have to argue over
On Thu, 4 Jan 2018, Tim Chen wrote:
> Set IBRS upon kernel entrance via syscall and interrupts. Clear it
> upon exit.
I have no idea on which kernel this is supposed to apply. It fails on Linus
tree and on tip x86/pti.
Can you please finally ditch the broken and outdated version of PTI on
which
> Dave Hansen wrote:
>> On 01/04/2018 08:51 PM, Andy Lutomirski wrote:
>> > Do we need an arch_prctl() to enable IBRS for user mode?
>>
>> Eventually, once the dust settles. I think there's a spectrum of
>> paranoia here, that is roughly (with increasing paranoia):
>>
>> 1. do nothing
>> 2. do
On Thu, 4 Jan 2018 21:11:23 -0800
Dave Hansen wrote:
> On 01/04/2018 08:51 PM, Andy Lutomirski wrote:
> > Do we need an arch_prctl() to enable IBRS for user mode?
>
> Eventually, once the dust settles. I think there's a spectrum of
> paranoia here, that is roughly (with increasing paranoia):
On 01/04/2018 08:51 PM, Andy Lutomirski wrote:
> Do we need an arch_prctl() to enable IBRS for user mode?
Eventually, once the dust settles. I think there's a spectrum of
paranoia here, that is roughly (with increasing paranoia):
1. do nothing
2. do retpoline
3. do IBRS in kernel
4. do IBRS alwa
On Thu, Jan 4, 2018 at 4:08 PM, Dave Hansen wrote:
> On 01/04/2018 02:33 PM, Peter Zijlstra wrote:
>> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>>> Set IBRS upon kernel entrance via syscall and interrupts. Clear it
>>> upon exit.
>>
>> So not only did we add a CR3 write, we're now
On 01/04/2018 02:33 PM, Peter Zijlstra wrote:
> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>> Set IBRS upon kernel entrance via syscall and interrupts. Clear it
>> upon exit.
>
> So not only did we add a CR3 write, we're now adding an MSR write to the
> entry/exit paths. Please tell
On Thu, Jan 04, 2018 at 11:33:21PM +0100, Peter Zijlstra wrote:
> So not only did we add a CR3 write, we're now adding an MSR write to the
> entry/exit paths. Please tell me that these are 'fast' MSRs? Given
> people are already reporting stupid numbers with just the existing
> PTI/CR3, what kind o
On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
> Set IBRS upon kernel entrance via syscall and interrupts. Clear it
> upon exit.
So not only did we add a CR3 write, we're now adding an MSR write to the
entry/exit paths. Please tell me that these are 'fast' MSRs? Given
people are already
On 01/04/2018 09:56 AM, Tim Chen wrote:
> If NMI runs when exiting kernel between IBRS_DISABLE and
> SWAPGS, the NMI would have turned on IBRS bit 0 and then it would have
> left enabled when exiting the NMI. IBRS bit 0 would then be left
> enabled in userland until the next enter kernel.
>
> That
On 01/04/2018 12:00 PM, Greg KH wrote:
> On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>>
>> That is a minor inefficiency only, but we can eliminate it by saving
>> the MSR when entering the NMI in save_paranoid and restoring it when
>> exiting the NMI.
>
> Any hints as to what exactly
On Thu, Jan 04, 2018 at 09:56:44AM -0800, Tim Chen wrote:
>
> That is a minor inefficiency only, but we can eliminate it by saving
> the MSR when entering the NMI in save_paranoid and restoring it when
> exiting the NMI.
Any hints as to what exactly "minor" means in cycles here? :)
thanks,
gre
Set IBRS upon kernel entrance via syscall and interrupts. Clear it
upon exit.
If NMI runs when exiting kernel between IBRS_DISABLE and
SWAPGS, the NMI would have turned on IBRS bit 0 and then it would have
left enabled when exiting the NMI. IBRS bit 0 would then be left
enabled in userland until t
13 matches
Mail list logo