On Tue, Jan 9, 2018 at 1:25 PM, Shuah Khan wrote:
> On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote:
>> This tests that the vsyscall entries do what they're expected to do.
>> It also confirms that attempts to read the vsyscall page behave as
>> expected.
>>
>> If changes are made to the v
On Thu, Jan 4, 2018 at 10:38 PM, Andy Lutomirski wrote:
> This tests that the vsyscall entries do what they're expected to do.
> It also confirms that attempts to read the vsyscall page behave as
> expected.
>
> If changes are made to the vsyscall code or its memory map handling,
> running this te
On Tue, Jan 09, 2018 at 05:15:15PM +0530, Naresh Kamboju wrote:
> We do not want to change the kernel command lines dynamically on
> the test bench. It will be hard to test this case in automated setup.
> Because with a given setup we run all selftests in a single go.
Those cmdline parameters are
On 5 January 2018 at 11:08, Andy Lutomirski wrote:
> This tests that the vsyscall entries do what they're expected to do.
> It also confirms that attempts to read the vsyscall page behave as
> expected.
>
> If changes are made to the vsyscall code or its memory map handling,
> running this test in
> On Jan 5, 2018, at 11:28 AM, Borislav Petkov wrote:
>
>> On Fri, Jan 05, 2018 at 11:22:21AM -0800, Andy Lutomirski wrote:
>> It's emulated! We catch the page fault and fake the whole thing :)
>
> Then I'm really confused. It says "ro" above, which means _PAGE_RW is
> not set so page is read-
On Fri, Jan 05, 2018 at 11:22:21AM -0800, Andy Lutomirski wrote:
> It's emulated! We catch the page fault and fake the whole thing :)
Then I'm really confused. It says "ro" above, which means _PAGE_RW is
not set so page is read-only.
I must be missing something...
--
Regards/Gruss,
Boris.
> On Jan 5, 2018, at 11:10 AM, Borislav Petkov wrote:
>
>> On Fri, Jan 05, 2018 at 10:45:49AM -0800, Andy Lutomirski wrote:
>> Not _PAGE_RW. Probably _PAGE_USER somewhere in the hierarchy.
>
> Yeah, just realized that. But it must be somewhere in the PT hierarchy
> because:
>
> 0xff6
On Fri, Jan 05, 2018 at 10:45:49AM -0800, Andy Lutomirski wrote:
> Not _PAGE_RW. Probably _PAGE_USER somewhere in the hierarchy.
Yeah, just realized that. But it must be somewhere in the PT hierarchy
because:
0xff60-0xff601000 4K USR ro
NX pte
On Fri, Jan 05, 2018 at 10:47:15AM -0800, Andy Lutomirski wrote:
> The remaining problem is that, for certain classes of userspace bugs,
> an attacker can take advantage of the vsyscall page's existence at a
> fixed address to cause mischief. So opting out of having it be there
> could be helpful
On Fri, Jan 5, 2018 at 10:23 AM, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 09:53:16AM -0800, Andy Lutomirski wrote:
>> emulate_noread would avoid one exploit technique that Kees saw
>> somewhere. And per-process disablement would let a system remain
>> compatible with old binaries without
On Fri, Jan 5, 2018 at 10:30 AM, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 10:01:23AM -0800, Andy Lutomirski wrote:
>> Yes. There are very clever tools like 'pin' that instrument a binary
>> by decoding all the instructions it executes and generating an
>> instrumented copy. If that binar
On Fri, Jan 05, 2018 at 10:01:23AM -0800, Andy Lutomirski wrote:
> Yes. There are very clever tools like 'pin' that instrument a binary
> by decoding all the instructions it executes and generating an
> instrumented copy. If that binary calls into the vDSO, the vDSO gets
> decoded and instrumente
On Fri, Jan 05, 2018 at 09:53:16AM -0800, Andy Lutomirski wrote:
> emulate_noread would avoid one exploit technique that Kees saw
> somewhere. And per-process disablement would let a system remain
> compatible with old binaries without reducing security for newer
> binaries.
Or we can simply say
On Fri, Jan 5, 2018 at 5:40 AM, Borislav Petkov wrote:
> On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote:
>> It's RFC because I want to re-read it myself first. It's also missing
>> a test that will reliably make sure that vsyscall=none prevents use of
>> vsyscalls.
>
> With my pa
On Fri, Jan 5, 2018 at 4:33 AM, Borislav Petkov wrote:
> On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote:
>> Also, I want to add vsyscall=emulate_noread that makes the vsyscall
>> page be --x. And I want to add a per-process option to turn off
>> vsyscalls.
>
> What for?
>
> It so
On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote:
> It's RFC because I want to re-read it myself first. It's also missing
> a test that will reliably make sure that vsyscall=none prevents use of
> vsyscalls.
With my patch ontop of 4.4 from yesterday:
# ./test_vsyscall_32
Warning:
On Thu, Jan 04, 2018 at 09:38:37PM -0800, Andy Lutomirski wrote:
> Also, I want to add vsyscall=emulate_noread that makes the vsyscall
> page be --x. And I want to add a per-process option to turn off
> vsyscalls.
What for?
It sounds like a bunch of work for something which is deprecated
anyway.
17 matches
Mail list logo
