On Fri, May 3, 2019 at 3:20 AM Ingo Molnar wrote:
> So what might work better is if we defined a Rust dialect that used C
> syntax. I.e. the end result would be something like the 'c2rust' or
> 'citrus' projects, where code like this would be directly translatable to
> Rust:
>
> void
* Robert O'Callahan wrote:
> On Sat, Apr 27, 2019 at 10:46 PM Ingo Molnar wrote:
> > - A C language runtime that is a subset of current C syntax and
> >semantics used in the kernel, and which doesn't allow access outside
> >of existing objects and thus creates a strictly enforced
On Sat, Apr 27, 2019 at 10:46 PM Ingo Molnar wrote:
> - A C language runtime that is a subset of current C syntax and
>semantics used in the kernel, and which doesn't allow access outside
>of existing objects and thus creates a strictly enforced separation
>between memory used for
* Peter Zijlstra wrote:
> On Tue, Apr 30, 2019 at 07:03:37AM +0200, Ingo Molnar wrote:
> > So the question IMHO isn't whether it's "valid C", because we already
> > have the Linux kernel's own C syntax variant and are enforcing it with
> > varying degrees of success.
>
> I'm not getting
On Tue, Apr 30, 2019 at 07:03:37AM +0200, Ingo Molnar wrote:
> So the question IMHO isn't whether it's "valid C", because we already
> have the Linux kernel's own C syntax variant and are enforcing it with
> varying degrees of success.
I'm not getting into the whole 'safe' fight here; but
* Andy Lutomirski wrote:
> On Sat, Apr 27, 2019 at 3:46 AM Ingo Molnar wrote:
> > So I'm wondering whether there's a 4th choice as well, which avoids
> > control flow corruption *before* it happens:
> >
> > - A C language runtime that is a subset of current C syntax and
> >semantics
On Sat, Apr 27, 2019 at 3:46 AM Ingo Molnar wrote:
>
>
> * Ingo Molnar wrote:
>
> > * Andy Lutomirski wrote:
> >
> > > > And no, I'm not arguing for Java or C#, but I am arguing for a saner
> > > > version of C.
> > >
> > > IMO three are three credible choices:
> > >
> > > 1. C with fairly
On Mon, Apr 29, 2019 at 11:27 AM James Morris wrote:
>
> On Sat, 27 Apr 2019, Ingo Molnar wrote:
>
> > - A C language runtime that is a subset of current C syntax and
> >semantics used in the kernel, and which doesn't allow access outside
> >of existing objects and thus creates a
On Sat, 27 Apr 2019, Ingo Molnar wrote:
> - A C language runtime that is a subset of current C syntax and
>semantics used in the kernel, and which doesn't allow access outside
>of existing objects and thus creates a strictly enforced separation
>between memory used for data, and
On Fri, Apr 26, 2019 at 09:49:56AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 26, 2019 at 12:45:49AM +0300, Mike Rapoport wrote:
> > The initial SCI implementation allows access to any kernel data, but it
> > limits access to the code in the following way:
> > * calls and jumps to known code
* Ingo Molnar wrote:
> * Andy Lutomirski wrote:
>
> > > And no, I'm not arguing for Java or C#, but I am arguing for a saner
> > > version of C.
> >
> > IMO three are three credible choices:
> >
> > 1. C with fairly strong CFI protection. Grsecurity has this (supposedly
> > — there’s a
* Andy Lutomirski wrote:
> > On Apr 26, 2019, at 2:58 AM, Ingo Molnar wrote:
> >
> >
> > * Ingo Molnar wrote:
> >
> >> I really don't like it where this is going. In a couple of years I
> >> really want to be able to think of PTI as a bad dream that is mostly
> >> over fortunately.
> >>
> >>
> On Apr 26, 2019, at 2:58 AM, Ingo Molnar wrote:
>
>
> * Ingo Molnar wrote:
>
>> I really don't like it where this is going. In a couple of years I
>> really want to be able to think of PTI as a bad dream that is mostly
>> over fortunately.
>>
>> I have the feeling that compiler level
> On Apr 26, 2019, at 11:49 AM, James Bottomley
> wrote:
>
> On Fri, 2019-04-26 at 10:40 -0700, Andy Lutomirski wrote:
>>> On Apr 26, 2019, at 8:19 AM, James Bottomley >> npartnership.com> wrote:
>>>
>>> On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
> On Apr 26, 2019, at
On Fri, 2019-04-26 at 10:40 -0700, Andy Lutomirski wrote:
> > On Apr 26, 2019, at 8:19 AM, James Bottomley > npartnership.com> wrote:
> >
> > On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
> > > > On Apr 26, 2019, at 7:57 AM, James Bottomley
> > > > wrote:
> > > >
> > > > > > On
> On Apr 26, 2019, at 8:19 AM, James Bottomley
> wrote:
>
> On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
>>> On Apr 26, 2019, at 7:57 AM, James Bottomley >> npartnership.com> wrote:
>>>
> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
> On 4/25/19 2:45 PM, Mike
On Fri, 2019-04-26 at 08:07 -0700, Andy Lutomirski wrote:
> > On Apr 26, 2019, at 7:57 AM, James Bottomley > npartnership.com> wrote:
> >
> > > On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
> > > > On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > > > After the isolated system call finishes,
> On Apr 26, 2019, at 7:57 AM, James Bottomley
> wrote:
>
>> On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
>>> On 4/25/19 2:45 PM, Mike Rapoport wrote:
>>> After the isolated system call finishes, the mappings created
>>> during its execution are cleared.
>>
>> Yikes. I guess that
On Fri, 2019-04-26 at 07:46 -0700, Dave Hansen wrote:
> On 4/25/19 2:45 PM, Mike Rapoport wrote:
> > After the isolated system call finishes, the mappings created
> > during its execution are cleared.
>
> Yikes. I guess that stops someone from calling write() a bunch of
> times on every
On 4/25/19 2:45 PM, Mike Rapoport wrote:
> After the isolated system call finishes, the mappings created during its
> execution are cleared.
Yikes. I guess that stops someone from calling write() a bunch of times
on every filesystem using every block device driver and all the DM code
to get a
On Fri, 2019-04-26 at 10:31 +0200, Ingo Molnar wrote:
> * Mike Rapoport wrote:
>
> > When enabled, the system call isolation (SCI) would allow execution
> > of the system calls with reduced page tables. These page tables are
> > almost identical to the user page tables in PTI. The only addition
* Ingo Molnar wrote:
> I really don't like it where this is going. In a couple of years I
> really want to be able to think of PTI as a bad dream that is mostly
> over fortunately.
>
> I have the feeling that compiler level protection that avoids
> corrupting the stack in the first place
* Mike Rapoport wrote:
> When enabled, the system call isolation (SCI) would allow execution of
> the system calls with reduced page tables. These page tables are almost
> identical to the user page tables in PTI. The only addition is the code
> page containing system call entry function
On Fri, Apr 26, 2019 at 12:45:49AM +0300, Mike Rapoport wrote:
> The initial SCI implementation allows access to any kernel data, but it
> limits access to the code in the following way:
> * calls and jumps to known code symbols without offset are allowed
> * calls and jumps into a known symbol
When enabled, the system call isolation (SCI) would allow execution of the
system calls with reduced page tables. These page tables are almost
identical to the user page tables in PTI. The only addition is the code
page containing system call entry function that will continue exectution
after the
25 matches
Mail list logo
