All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexandre Chartre <alexandre.chartre@oracle.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	Jonathan Adams <jwadams@google.com>,
	Kees Cook <keescook@chromium.org>, Paul Turner <pjt@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux-MM <linux-mm@kvack.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	X86 ML <x86@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation
Date: Tue, 30 Apr 2019 13:05:49 +0200	[thread overview]
Message-ID: <20190430110549.GA119957@gmail.com> (raw)
In-Reply-To: <20190430093857.GO2623@hirez.programming.kicks-ass.net>


* Peter Zijlstra <peterz@infradead.org> 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 into the whole 'safe' fight here; but you're under
> selling things. We don't have a C syntax, we have a full blown C
> lanugeage variant.
> 
> The 'Kernel C' that we write is very much not 'ANSI/ISO C' anymore in a
> fair number of places. And if I can get my way, we'll only diverge
> further from the standard.

Yeah, but I think it would be fair to say that random style variations 
aside, in the kernel we still allow about 95%+ of 'sensible C'.

> And this is quite separate from us using every GCC extention under the 
> sun; which of course also doesn't help. It mostly has to do with us 
> treating C as a portable assembler and the C people not wanting to 
> commit to sensible things because they think C is a high-level 
> language.

Indeed, and also because there's arguably somewhat of a "if the spec 
allows it then performance first, common-sense semantics second" mindset. 
Which is an understandable social dynamic, as compiler developers tend to 
distinguish themselves via the optimizations they've authored.

Anyway, the main point I tried to make is that I think we'd still be able 
to allow 95%+ of "sensible C" even if executed in a "safe runtime", and 
we'd still be able to build and run without such strong runtime type 
enforcement, i.e. get kernel code close to what we have today, minus a 
handful of optimizations and data structures. (But the performance costs 
even in that case are nonzero - I'm not sugarcoating it.)

( Plus even that isn't a fully secure solution with deterministic 
  outcomes, due to parallelism and data races. )

Thanks,

	Ingo

  reply	other threads:[~2019-04-30 11:05 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-25 21:45 [RFC PATCH 0/7] x86: introduce system calls addess space isolation Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 1/7] x86/cpufeatures: add X86_FEATURE_SCI Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 2/7] x86/sci: add core implementation for system call isolation Mike Rapoport
2019-04-26  7:49   ` Peter Zijlstra
2019-04-28  5:45     ` Mike Rapoport
2019-04-26  8:31   ` Ingo Molnar
2019-04-26  9:58     ` Ingo Molnar
2019-04-26 21:26       ` Andy Lutomirski
2019-04-26 21:26         ` Andy Lutomirski
2019-04-27  8:47         ` Ingo Molnar
2019-04-27 10:46           ` Ingo Molnar
2019-04-29 18:26             ` James Morris
2019-04-29 18:43               ` Andy Lutomirski
2019-04-29 18:43                 ` Andy Lutomirski
2019-04-29 18:46             ` Andy Lutomirski
2019-04-29 18:46               ` Andy Lutomirski
2019-04-30  5:03               ` Ingo Molnar
2019-04-30  9:38                 ` Peter Zijlstra
2019-04-30 11:05                   ` Ingo Molnar [this message]
2019-05-02 11:35             ` Robert O'Callahan
2019-05-02 11:35               ` Robert O'Callahan
2019-05-02 15:20               ` Ingo Molnar
2019-05-02 21:07                 ` Robert O'Callahan
2019-05-02 21:07                   ` Robert O'Callahan
2019-04-26 14:44     ` James Bottomley
2019-04-26 14:44       ` James Bottomley
2019-04-26 14:46   ` Dave Hansen
2019-04-26 14:57     ` James Bottomley
2019-04-26 14:57       ` James Bottomley
2019-04-26 15:07       ` Andy Lutomirski
2019-04-26 15:19         ` James Bottomley
2019-04-26 15:19           ` James Bottomley
2019-04-26 17:40           ` Andy Lutomirski
2019-04-26 18:49             ` James Bottomley
2019-04-26 18:49               ` James Bottomley
2019-04-26 19:22               ` Andy Lutomirski
2019-04-25 21:45 ` [RFC PATCH 3/7] x86/entry/64: add infrastructure for switching to isolated syscall context Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 4/7] x86/sci: hook up isolated system call entry and exit Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 5/7] x86/mm/fault: hook up SCI verification Mike Rapoport
2019-04-26  7:42   ` Peter Zijlstra
2019-04-28  5:47     ` Mike Rapoport
2019-04-30 16:44       ` Andy Lutomirski
2019-04-30 16:44         ` Andy Lutomirski
2019-05-01  5:39         ` Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 6/7] security: enable system call isolation in kernel config Mike Rapoport
2019-04-25 21:45 ` [RFC PATCH 7/7] sci: add example system calls to exercse SCI Mike Rapoport
2019-04-26  0:30 ` [RFC PATCH 0/7] x86: introduce system calls addess space isolation Andy Lutomirski
2019-04-26  0:30   ` Andy Lutomirski
2019-04-26  8:07   ` Jiri Kosina
2019-04-28  6:01   ` Mike Rapoport
2019-04-26 14:41 ` Dave Hansen
2019-04-28  6:08   ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190430110549.GA119957@gmail.com \
    --to=mingo@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexandre.chartre@oracle.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jwadams@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=rppt@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.