headers
Jesper Juhl | 1 Jul 2011 12:46
Favicon
Gravatar

[PATCH] Update version number references in README

When 3.0 is released I believe the README should reflect the new
numbering.

Signed-off-by: Jesper Juhl <jj <at> chaosbits.net>
---
 README |   42 +++++++++++++++++++++---------------------
 1 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/README b/README
index 8510017..0d5a7dd 100644
--- a/README
+++ b/README
 <at>  <at>  -1,6 +1,6  <at>  <at> 
-	Linux kernel release 2.6.xx <http://kernel.org/>
+	Linux kernel release 3.x <http://kernel.org/>

-These are the release notes for Linux version 2.6.  Read them carefully,
+These are the release notes for Linux version 3.  Read them carefully,
 as they tell you what this is all about, explain how to install the
 kernel, and what to do if something goes wrong. 

 <at>  <at>  -62,10 +62,10  <at>  <at>  INSTALLING the kernel source:
    directory where you have permissions (eg. your home directory) and
    unpack it:

-		gzip -cd linux-2.6.XX.tar.gz | tar xvf -
+		gzip -cd linux-3.X.tar.gz | tar xvf -

    or
-		bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf -
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ingo Molnar | 1 Jul 2011 13:56
Picon
Picon
Favicon

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.


* James Morris <jmorris <at> namei.org> wrote:

> On Wed, 29 Jun 2011, Will Drewry wrote:
> 
> > Since it seems that there'll be consumers (openssh, vsftpd, 
> > kvm/qemu, chromium, chromium os) and feedback quieted down, what 
> > are the next steps to get this to a pull/no-pull decision points 
> > (or at least some Ack's or Nack's)?  I know this patch series 
> > crosses a number of maintainers, and I never know exactly what's 
> > next when the feedback slows down.
> 
> Are there any outstanding objections to this approach?  How do the 
> tracing folk feel about it?

I think i outlined my objections a couple of times and haven't seen 
them addressed.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 21 comments |
headers
Ingo Molnar | 1 Jul 2011 14:04
Picon
Picon
Favicon

Re: [RFC] ipc: introduce shm_rmid_forced sysctl


* Vasiliy Kulikov <segoon <at> openwall.com> wrote:

> On Fri, Jul 01, 2011 at 13:25 +0200, Ingo Molnar wrote:
> > Furthermore, if testing shows that this is not actually breaking 
> > anything in a serious way we could also in theory simplify the patch 
> > and just make this the default behavior with no runtime ability to 
> > switch it off.
> 
> I'm afraid it's impossible.  From -ow readme:
> 
> "Of course, this breaks the way things are defined, so some 
> applications might stop working. In particular, expect most 
> commercial databases to break. Apache and PostgreSQL are known to 
> work, though. :-)"
> 
> http://www.openwall.com/linux/README.shtml
> 
> But as it was written in days of Linux 2.4.x, the situation could 
> have changed.  A desktop system seems to work.

As we really prefer working systems over non-working ones (and lots 
of unattached shm segments can clearly result in a non-working 
system) we can only accept the "this will break stuff" argument if 
it's *demonstrated* to break stuff and if the failure scenario is 
carefully described in the commit.

It would take a serious breakage to override a "system locks up 
swapping itself to death" failure scenario.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ingo Molnar | 1 Jul 2011 15:07
Picon
Picon
Favicon

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.


* Will Drewry <wad <at> chromium.org> wrote:

> On Fri, Jul 1, 2011 at 6:56 AM, Ingo Molnar <mingo <at> elte.hu> wrote:
> >
> > * James Morris <jmorris <at> namei.org> wrote:
> >
> >> On Wed, 29 Jun 2011, Will Drewry wrote:
> >>
> >> > Since it seems that there'll be consumers (openssh, vsftpd,
> >> > kvm/qemu, chromium, chromium os) and feedback quieted down, what
> >> > are the next steps to get this to a pull/no-pull decision points
> >> > (or at least some Ack's or Nack's)?  I know this patch series
> >> > crosses a number of maintainers, and I never know exactly what's
> >> > next when the feedback slows down.
> >>
> >> Are there any outstanding objections to this approach?  How do the
> >> tracing folk feel about it?
> >
> > I think i outlined my objections a couple of times and haven't seen
> > them addressed.
> 
> After our last discussion, I suggested changes which I then undertook
> and reposted.  Those changes have been posted for over two weeks.

Have you addressed my basic objection of why we should go for a more 
complex and less capable variant over a shared yet more capable 
facility:

  http://lkml.kernel.org/r/20110526091518.GE26775 <at> elte.hu
(Continue reading)

Permalink | Reply | 19 comments |
headers
Alan Cox | 1 Jul 2011 16:18
Face
Picon

Re: [RFC] ipc: introduce shm_rmid_forced sysctl

> As we really prefer working systems over non-working ones (and lots 
> of unattached shm segments can clearly result in a non-working 
> system) we can only accept the "this will break stuff" argument if 
> it's *demonstrated* to break stuff and if the failure scenario is 
> carefully described in the commit.
> 
> It would take a serious breakage to override a "system locks up 
> swapping itself to death" failure scenario.

Ths shared memory interface is defined to be persistent for good reason
and all sorts of apps rely upon that so no you can't just ignore that. As
a configurable alternative it makes sense (indeed many SYS5 admins used
to run shared memory segment sweepers to clean up long idle ones)

However if it's locking the machine up and not being properly handled by
resource management then

a) your resource management is broken so fix that instead
b) if your resource management is busted or you are not properly
tracking resource commits then the user is going to be able to achieve the
same result by other means (eg a unix domain socket bomb)

If you've got no overcommit set you shouldn't be able to swap to death,
it may be the sysv shared memory objects need to be accounted for
specifically somewhere but that would be the right thing to fix and the
mechanisms to do it exist.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ingo Molnar | 1 Jul 2011 18:10
Picon
Picon
Favicon

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.


* Will Drewry <wad <at> chromium.org> wrote:

> From my view, ftrace events are not ready for the job yet - and 
> relying purely on available wrapped events may make it unsuitable 
> for attack surface reduction forever.  As is, there is no compat 
> syscall support.  Many syscalls are not wrapped at present and no 
> one ack'd my earlier patches around wrapping more.  All of perf 
> needs to be overhauled to share per-task infrastructure. A new ABI 
> needs to be proposed if my prctl() changes are not acceptable to 
> handle some of the security-focused behavioral requirements.  
> Performance characteristics need to be better analyzed as the 
> current perf list_head approach may not scale as desired.  The list 
> goes on.  My proof of concept patch for "event filters" was just 
> that - a proof of concept.  To truly share the filter events is a 
> large amount of work that may not be viable, and I believe you know 
> that as well as I do.

But that's exactly my point: i consider it the right way forward 
because it maximizes kernel utility in the long run.

Note that *all* the specific technical items you mention:

 - wrapping more syscalls (i.e. making syscall tracing
   feature-complete)

 - a clean filtering ABI

 - performance improvements. (Note that this one is already
   in progress, Thomas has written an IDR implementation that
(Continue reading)

Permalink | Reply | 16 comments |
headers
Will Drewry | 1 Jul 2011 18:43

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.

On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo <at> elte.hu> wrote:
>
> * Will Drewry <wad <at> chromium.org> wrote:
>
>> From my view, ftrace events are not ready for the job yet - and
>> relying purely on available wrapped events may make it unsuitable
>> for attack surface reduction forever.  As is, there is no compat
>> syscall support.  Many syscalls are not wrapped at present and no
>> one ack'd my earlier patches around wrapping more.  All of perf
>> needs to be overhauled to share per-task infrastructure. A new ABI
>> needs to be proposed if my prctl() changes are not acceptable to
>> handle some of the security-focused behavioral requirements.
>> Performance characteristics need to be better analyzed as the
>> current perf list_head approach may not scale as desired.  The list
>> goes on.  My proof of concept patch for "event filters" was just
>> that - a proof of concept.  To truly share the filter events is a
>> large amount of work that may not be viable, and I believe you know
>> that as well as I do.
>
> But that's exactly my point: i consider it the right way forward
> because it maximizes kernel utility in the long run.

Not if it never happens.  Which is what happened with the proposals
from Adam and from Eric.

> Note that *all* the specific technical items you mention:
>
>  - wrapping more syscalls (i.e. making syscall tracing
>   feature-complete)
>
(Continue reading)

Permalink | Reply | 15 comments |
headers
Steven Rostedt | 1 Jul 2011 20:04
Gravatar

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.

On Fri, 2011-07-01 at 11:43 -0500, Will Drewry wrote:
> On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo <at> elte.hu> wrote:

> I'd like to be able to move along security for the platform today and
> not in two years, but if my only chance of any form of this being
> ACK'd is to write it such that it shares code with perf and has a
> shiny new ABI, then I'll queue up the work for when I can start trying
> to tackle it.

As this seems to be dragging on, and does not look to be solved by
October, I would like to propose this topic for the Kernel Summit in
Prague. I believe all parties involved may be there, and if not, I will
push hard to get them there.

Email is not always the best median for discussions. Face to face can
usually solve things much quicker.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 10 comments |
headers
Will Drewry | 1 Jul 2011 20:09

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.

On Fri, Jul 1, 2011 at 1:04 PM, Steven Rostedt <rostedt <at> goodmis.org> wrote:
> On Fri, 2011-07-01 at 11:43 -0500, Will Drewry wrote:
>> On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo <at> elte.hu> wrote:
>
>> I'd like to be able to move along security for the platform today and
>> not in two years, but if my only chance of any form of this being
>> ACK'd is to write it such that it shares code with perf and has a
>> shiny new ABI, then I'll queue up the work for when I can start trying
>> to tackle it.
>
> As this seems to be dragging on, and does not look to be solved by
> October, I would like to propose this topic for the Kernel Summit in
> Prague. I believe all parties involved may be there, and if not, I will
> push hard to get them there.
>
> Email is not always the best median for discussions. Face to face can
> usually solve things much quicker.

I have a panel reserved on system/kernel hardening with Kees at the
Linux Security Summit as part of the LPC (thanks to the LSS
committee).  Will the relevant people be able to attend that in
September?

(Since the KS is invite-only, I'm obviously not on the list for it,
but I realize I'm just a bit player in this. Maybe some direction can
be resolved I can play catch up with.)

What's another couple months? :)

Thanks!
(Continue reading)

Permalink | Reply | 7 comments |
headers
Kees Cook | 1 Jul 2011 22:25
Favicon
Gravatar

Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.

On Fri, Jul 01, 2011 at 02:04:08PM -0400, Steven Rostedt wrote:
> On Fri, 2011-07-01 at 11:43 -0500, Will Drewry wrote:
> > On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo <at> elte.hu> wrote:
> 
> > I'd like to be able to move along security for the platform today and
> > not in two years, but if my only chance of any form of this being
> > ACK'd is to write it such that it shares code with perf and has a
> > shiny new ABI, then I'll queue up the work for when I can start trying
> > to tackle it.
> 
> As this seems to be dragging on, and does not look to be solved by
> October, I would like to propose this topic for the Kernel Summit in
> Prague. I believe all parties involved may be there, and if not, I will
> push hard to get them there.
> 
> Email is not always the best median for discussions. Face to face can
> usually solve things much quicker.

How about we put it in as-is and mark it experimental, and then folks
can discuss improvements to it in Oct after all the API users have had
a chance to play with it? Four months seems like a needless delay to me.
I respect the objections, but it doesn't seem to balance against the
demonstrated need for this feature when faced with a viable working patch
series.

-Kees

--

-- 
Kees Cook
Ubuntu Security Team
(Continue reading)

Permalink | Reply | 1 comment |

Gmane