From: Andi Kleen <ak@muc.de>
To: Andrea Arcangeli <andrea@cpushare.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: secure computing for 2.6.7
Date: Mon, 02 Aug 2004 02:05:20 +0200 [thread overview]
Message-ID: <m3ekmq2ym7.fsf@averell.firstfloor.org> (raw)
In-Reply-To: <2olLt-4wI-5@gated-at.bofh.it> (Andrea Arcangeli's message of "Sun, 01 Aug 2004 12:30:11 +0200")
Andrea Arcangeli <andrea@cpushare.com> writes:
> +/*
> + * bump this sequence number after fixing any kernel security bug
> + * that could render insecure some userspace application. This
> + * way future versions of the userpace application will be able
> + * to reliably make sure to run on a secure kernel.
> + * I hope 31bit are enough... ;).
> + */
> +static int security_sequence;
I don't think a sequence number is a good idea. Consider a
vendor/third party kernel fixing a security bug, but mainline hasn't
taken the patch yet for some reason.
The vendor kernel could not safely increase this number, because it
could conflict with some other security bug fixed in mainline at the
same time.
The end result would be that the kernel would be fixed, but
the application has no way to tell.
Better may be a bitmap, but even there you still have an problem
with allocating these bits.
A safe solution would be a file in /proc that lists CAN idenitifiers of
fixed bugs or similar, but that may be quite some overhead to maintain
and parse.
-Andi
next parent reply other threads:[~2004-08-02 0:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2ejhQ-4lc-5@gated-at.bofh.it>
[not found] ` <2fqhq-1RU-45@gated-at.bofh.it>
[not found] ` <2olLt-4wI-5@gated-at.bofh.it>
2004-08-02 0:05 ` Andi Kleen [this message]
2004-08-02 10:19 ` secure computing for 2.6.7 Andrea Arcangeli
2004-08-02 19:06 ` Rik van Riel
2004-08-02 21:35 ` Andrea Arcangeli
2004-08-04 13:18 ` V13
2004-07-04 17:39 andrea
2004-07-04 21:35 ` Andrew Morton
2004-07-04 23:32 ` andrea
2004-07-05 0:37 ` Phy Prabab
2004-10-12 14:24 ` Andrea Arcangeli
2004-10-12 15:32 ` Rik van Riel
2004-10-12 15:59 ` Andrea Arcangeli
2004-10-12 16:28 ` Rik van Riel
2004-10-12 17:46 ` Andrea Arcangeli
2004-10-12 18:04 ` Rik van Riel
2004-10-12 18:10 ` Rik van Riel
2004-10-12 18:29 ` Andrea Arcangeli
2004-07-07 19:27 ` Hans Reiser
2004-08-01 10:22 ` Andrea Arcangeli
2004-08-01 12:01 ` chris
2004-08-01 15:01 ` Andrea Arcangeli
2004-08-01 17:29 ` chris
2004-08-01 18:52 ` Bernd Eckenfels
2004-08-01 20:45 ` Alan Cox
2004-08-01 23:10 ` Andrea Arcangeli
2004-08-01 23:08 ` Alan Cox
2004-08-02 10:25 ` Andrea Arcangeli
2004-08-01 23:06 ` Andrea Arcangeli
2004-08-02 6:52 ` David Wagner
2004-08-03 12:48 ` Stephen Smalley
2004-08-01 14:55 ` Bernd Eckenfels
2004-08-01 15:51 ` Andrea Arcangeli
2004-08-01 17:24 ` Bernd Eckenfels
2004-08-02 3:17 ` Horst von Brand
2004-08-02 16:31 ` Andrea Arcangeli
2004-08-03 12:40 ` Stephen Smalley
2004-08-03 21:02 ` Alexander Lyamin
2004-08-05 11:47 ` Stephen Smalley
2004-08-04 8:57 ` Hans Reiser
2004-08-05 11:48 ` Stephen Smalley
2004-08-07 23:20 ` Hans Reiser
2004-08-09 12:35 ` Stephen Smalley
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=m3ekmq2ym7.fsf@averell.firstfloor.org \
--to=ak@muc.de \
--cc=andrea@cpushare.com \
--cc=linux-kernel@vger.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