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.
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 all three of vsyscall=none, vsyscall=emulate,
and vsyscall=nat
18 matches
Mail list logo
