On Mon, Nov 13, 2017 at 1:07 PM, Dave Hansen
wrote:
> On 11/12/2017 07:52 PM, Andy Lutomirski wrote:
>> On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen
>> wrote:
>>> On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
I have nothing against
On Mon, Nov 13, 2017 at 1:07 PM, Dave Hansen
wrote:
> On 11/12/2017 07:52 PM, Andy Lutomirski wrote:
>> On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen
>> wrote:
>>> On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
I have nothing against disabling native. I object to breaking the
weird
On 11/12/2017 07:52 PM, Andy Lutomirski wrote:
> On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen
> wrote:
>> On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
>>> I have nothing against disabling native. I object to breaking the
>>> weird binary tracing behavior in the
On 11/12/2017 07:52 PM, Andy Lutomirski wrote:
> On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen
> wrote:
>> On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
>>> I have nothing against disabling native. I object to breaking the
>>> weird binary tracing behavior in the emulation mode, especially if
On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen
wrote:
> On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
>> On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen
>> wrote:
>>> On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
Here are two proposals
On Fri, Nov 10, 2017 at 3:04 PM, Dave Hansen
wrote:
> On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
>> On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen
>> wrote:
>>> On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
Here are two proposals to address this without breaking vsyscalls.
1.
On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
> On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen
> wrote:
>> On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
>>> Here are two proposals to address this without breaking vsyscalls.
>>>
>>> 1. Set NX on low mappings that are
On 11/10/2017 02:06 PM, Andy Lutomirski wrote:
> On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen
> wrote:
>> On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
>>> Here are two proposals to address this without breaking vsyscalls.
>>>
>>> 1. Set NX on low mappings that are _PAGE_USER. Don't set NX on
On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen
wrote:
> On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
>> Here are two proposals to address this without breaking vsyscalls.
>>
>> 1. Set NX on low mappings that are _PAGE_USER. Don't set NX on high
>> mappings but,
On Thu, Nov 9, 2017 at 10:31 PM, Dave Hansen
wrote:
> On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
>> Here are two proposals to address this without breaking vsyscalls.
>>
>> 1. Set NX on low mappings that are _PAGE_USER. Don't set NX on high
>> mappings but, optionally, warn if you see
From: Dave Hansen
The KAISER code attempts to "poison" the user portion of the kernel page
tables. It detects entries that it wants that it wants to poison in two
ways:
* Looking for addresses >= PAGE_OFFSET
* Looking for entries without _PAGE_USER set
But, to
From: Dave Hansen
The KAISER code attempts to "poison" the user portion of the kernel page
tables. It detects entries that it wants that it wants to poison in two
ways:
* Looking for addresses >= PAGE_OFFSET
* Looking for entries without _PAGE_USER set
But, to allow the _PAGE_USER check to
On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
> Here are two proposals to address this without breaking vsyscalls.
>
> 1. Set NX on low mappings that are _PAGE_USER. Don't set NX on high
> mappings but, optionally, warn if you see _PAGE_USER on any address
> that isn't the vsyscall page.
>
>
On 11/09/2017 06:25 PM, Andy Lutomirski wrote:
> Here are two proposals to address this without breaking vsyscalls.
>
> 1. Set NX on low mappings that are _PAGE_USER. Don't set NX on high
> mappings but, optionally, warn if you see _PAGE_USER on any address
> that isn't the vsyscall page.
>
>
On Thu, Nov 9, 2017 at 5:22 PM, Dave Hansen wrote:
> On 11/09/2017 05:04 PM, Andy Lutomirski wrote:
>> On Thu, Nov 9, 2017 at 4:57 PM, Dave Hansen
>> wrote:
>>> On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
> The KAISER code
On Thu, Nov 9, 2017 at 5:22 PM, Dave Hansen wrote:
> On 11/09/2017 05:04 PM, Andy Lutomirski wrote:
>> On Thu, Nov 9, 2017 at 4:57 PM, Dave Hansen
>> wrote:
>>> On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
> The KAISER code attempts to "poison" the user portion of the kernel page
>
On 11/09/2017 05:04 PM, Andy Lutomirski wrote:
> On Thu, Nov 9, 2017 at 4:57 PM, Dave Hansen
> wrote:
>> On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
The KAISER code attempts to "poison" the user portion of the kernel page
tables. It detects the entries
On 11/09/2017 05:04 PM, Andy Lutomirski wrote:
> On Thu, Nov 9, 2017 at 4:57 PM, Dave Hansen
> wrote:
>> On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
The KAISER code attempts to "poison" the user portion of the kernel page
tables. It detects the entries pages that it wants that it
On Thu, Nov 9, 2017 at 4:57 PM, Dave Hansen wrote:
> On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
>>> The KAISER code attempts to "poison" the user portion of the kernel page
>>> tables. It detects the entries pages that it wants that it wants to
>>> poison in two
On Thu, Nov 9, 2017 at 4:57 PM, Dave Hansen wrote:
> On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
>>> The KAISER code attempts to "poison" the user portion of the kernel page
>>> tables. It detects the entries pages that it wants that it wants to
>>> poison in two ways:
>>> * Looking for
On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
>> The KAISER code attempts to "poison" the user portion of the kernel page
>> tables. It detects the entries pages that it wants that it wants to
>> poison in two ways:
>> * Looking for addresses >= PAGE_OFFSET
>> * Looking for entries without
On 11/09/2017 04:53 PM, Andy Lutomirski wrote:
>> The KAISER code attempts to "poison" the user portion of the kernel page
>> tables. It detects the entries pages that it wants that it wants to
>> poison in two ways:
>> * Looking for addresses >= PAGE_OFFSET
>> * Looking for entries without
On Thu, Nov 9, 2017 at 11:26 AM, Dave Hansen
wrote:
> On 11/09/2017 11:04 AM, Andy Lutomirski wrote:
>> On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
>> wrote:
>>>
>>> From: Dave Hansen
>>>
>>> The VSYSCALL
On Thu, Nov 9, 2017 at 11:26 AM, Dave Hansen
wrote:
> On 11/09/2017 11:04 AM, Andy Lutomirski wrote:
>> On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
>> wrote:
>>>
>>> From: Dave Hansen
>>>
>>> The VSYSCALL page is mapped by kernel page tables at a kernel address.
>>> It is troublesome to
On 11/09/2017 11:04 AM, Andy Lutomirski wrote:
> On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
> wrote:
>>
>> From: Dave Hansen
>>
>> The VSYSCALL page is mapped by kernel page tables at a kernel address.
>> It is troublesome to support
On 11/09/2017 11:04 AM, Andy Lutomirski wrote:
> On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
> wrote:
>>
>> From: Dave Hansen
>>
>> The VSYSCALL page is mapped by kernel page tables at a kernel address.
>> It is troublesome to support with KAISER in place, so disable the
>> native case.
>>
>>
On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
wrote:
>
> From: Dave Hansen
>
> The VSYSCALL page is mapped by kernel page tables at a kernel address.
> It is troublesome to support with KAISER in place, so disable the
> native case.
>
>
On Wed, Nov 8, 2017 at 11:47 AM, Dave Hansen
wrote:
>
> From: Dave Hansen
>
> The VSYSCALL page is mapped by kernel page tables at a kernel address.
> It is troublesome to support with KAISER in place, so disable the
> native case.
>
> Also add some help text about how KAISER might affect the
From: Dave Hansen
The VSYSCALL page is mapped by kernel page tables at a kernel address.
It is troublesome to support with KAISER in place, so disable the
native case.
Also add some help text about how KAISER might affect the emulation
case as well.
Signed-off-by:
From: Dave Hansen
The VSYSCALL page is mapped by kernel page tables at a kernel address.
It is troublesome to support with KAISER in place, so disable the
native case.
Also add some help text about how KAISER might affect the emulation
case as well.
Signed-off-by: Dave Hansen
Cc: Moritz Lipp
30 matches
Mail list logo