> Is this compatible with existing userspace? CRIU and DOSEMU seem like
> things that are likely to blow up to me.
It should at least make it a sysctl.
>
> We may need to make this type of mitigation be opt-in. I'm already
> vaguely planning an opt-in mitigation framework for vsyscall runtime
> Is this compatible with existing userspace? CRIU and DOSEMU seem like
> things that are likely to blow up to me.
It should at least make it a sysctl.
>
> We may need to make this type of mitigation be opt-in. I'm already
> vaguely planning an opt-in mitigation framework for vsyscall runtime
On Feb 8, 2016 3:17 PM, "Scotty Bauer" wrote:
>
>
>
> On 02/08/2016 02:50 PM, Andy Lutomirski wrote:
> > On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
> >>
> >>
> >> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
> >>> Hi,
> >>>
> >>>
> >>> On 07.02.2016 01:39, Scott Bauer wrote:
>
On 02/08/2016 02:50 PM, Andy Lutomirski wrote:
> On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
>>
>>
>> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
>>> Hi,
>>>
>>>
>>> On 07.02.2016 01:39, Scott Bauer wrote:
This patch adds SROP mitigation logic to the x86 signal delivery
and
On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
>
>
> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
>> Hi,
>>
>>
>> On 07.02.2016 01:39, Scott Bauer wrote:
>>> This patch adds SROP mitigation logic to the x86 signal delivery
>>> and sigreturn code. The cookie is placed in the unused alignment
On Feb 8, 2016 3:17 PM, "Scotty Bauer" wrote:
>
>
>
> On 02/08/2016 02:50 PM, Andy Lutomirski wrote:
> > On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
> >>
> >>
> >> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
> >>> Hi,
> >>>
> >>>
> >>> On
On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
>
>
> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
>> Hi,
>>
>>
>> On 07.02.2016 01:39, Scott Bauer wrote:
>>> This patch adds SROP mitigation logic to the x86 signal delivery
>>> and sigreturn code. The cookie is placed in
On 02/08/2016 02:50 PM, Andy Lutomirski wrote:
> On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
>>
>>
>> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
>>> Hi,
>>>
>>>
>>> On 07.02.2016 01:39, Scott Bauer wrote:
This patch adds SROP mitigation logic to the x86
On 02/06/2016 11:35 PM, Mika Penttilä wrote:
> Hi,
>
>
> On 07.02.2016 01:39, Scott Bauer wrote:
>> This patch adds SROP mitigation logic to the x86 signal delivery
>> and sigreturn code. The cookie is placed in the unused alignment
>> space above the saved FP state, if it exists. If there is
On 02/06/2016 11:35 PM, Mika Penttilä wrote:
> Hi,
>
>
> On 07.02.2016 01:39, Scott Bauer wrote:
>> This patch adds SROP mitigation logic to the x86 signal delivery
>> and sigreturn code. The cookie is placed in the unused alignment
>> space above the saved FP state, if it exists. If there is
Hi,
On 07.02.2016 01:39, Scott Bauer wrote:
> This patch adds SROP mitigation logic to the x86 signal delivery
> and sigreturn code. The cookie is placed in the unused alignment
> space above the saved FP state, if it exists. If there is no FP
> state to save then the cookie is placed in the
This patch adds SROP mitigation logic to the x86 signal delivery
and sigreturn code. The cookie is placed in the unused alignment
space above the saved FP state, if it exists. If there is no FP
state to save then the cookie is placed in the alignment space above
the sigframe.
Cc: Abhiram
This patch adds SROP mitigation logic to the x86 signal delivery
and sigreturn code. The cookie is placed in the unused alignment
space above the saved FP state, if it exists. If there is no FP
state to save then the cookie is placed in the alignment space above
the sigframe.
Cc: Abhiram
Hi,
On 07.02.2016 01:39, Scott Bauer wrote:
> This patch adds SROP mitigation logic to the x86 signal delivery
> and sigreturn code. The cookie is placed in the unused alignment
> space above the saved FP state, if it exists. If there is no FP
> state to save then the cookie is placed in the
14 matches
Mail list logo