[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <85367e7juc.fsf@collabora.com>
Date: Mon, 01 Jun 2020 13:54:19 -0400
From: Gabriel Krisman Bertazi <krisman@...labora.com>
To: Paul Gofman <gofmanp@...il.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Kees Cook <keescook@...omium.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, kernel@...labora.com,
Thomas Gleixner <tglx@...utronix.de>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>,
"H . Peter Anvin" <hpa@...or.com>,
linux-security-module@...r.kernel.org,
Zebediah Figura <zfigura@...eweavers.com>
Subject: Re: [PATCH RFC] seccomp: Implement syscall isolation based on memory areas
Paul Gofman <gofmanp@...il.com> writes:
> On 5/31/20 20:31, Matthew Wilcox wrote:
>> If it's the cost of the syscall that's the problem, there are ways
>> around that. We'd still want a personality() call to indicate that
>> the syscall handler should look (somewhere) to determine the current
>> personality, but that could be issued at the start of execution rather
>> than when we switch between Windows & Linux code.
>
> Sure, we can call personality() at start and specify the location to
> look at, the only thing is that the location should be thread specific,
> that is, based on fs: or gs: or whatever else which would allow us to
> have different threads in different "personality" state. If anything
> needs to be set up at thread start we can do that also of course.
>
> If there will be any proof of concept solution I will be happy to make a
> proof of concept Wine patch using that and do some testing.
Let me give that a try and share the patches with you, so we can look at
how this implementation would look like.
--
Gabriel Krisman Bertazi
Powered by blists - more mailing lists