linux-kernel.vger.kernel.org archive mirror
 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: 41+ 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-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: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 15:20               ` Ingo Molnar
2019-05-02 21:07                 ` Robert O'Callahan
2019-04-26 14:44     ` James Bottomley
2019-04-26 14:46   ` Dave Hansen
2019-04-26 14:57     ` James Bottomley
2019-04-26 15:07       ` Andy Lutomirski
2019-04-26 15:19         ` James Bottomley
2019-04-26 17:40           ` Andy Lutomirski
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-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  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).