RE: crypto (was Re: Congrats Marcelo,)

RE: crypto (was Re: Congrats Marcelo,)

[Dennis, Jim]

> Andreas Dilger wrote:
>> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
>>>  Now I need to know about the status of several unofficial patches:

>>>       i2c
>>>       Crypto
>>>       FreeS/WAN KLIPS
>>>       LIDS
 
>> No idea.

> I would -love- to see crypto in the mainstream kernel.  Distribution of
> crypto software on kernel.org has been OK for a while now.

> Who knows what the kerneli guys, freeswan, etc. guys think.

> IMO it's time to get a good IPsec implementation in the kernel...

>	Jeff

 I think some people may have misinterpreted my question.  I was actually 
 asking about how soon the maintainers of these unofficial patches will
 be updating their patches to apply cleanly to 2.4.18 (and hopefully in
 conjunction with one another).  I wasn't actually asking when or if these
 would be merged into the mainstream.

 I understand that XFS is not slated for 2.4.x merging; and I presume that
the
 ACL and extended ACL stuff is also slated to remain separate.  I also
understand
 the wariness of the kernel maintainers regarding any inclusion of the
crypto
 code in mainstream given the ongoing U.S. and international political and
legal
 issues that are STILL associated with it.  (Who was it who said that
"reform
 is the enemy of revolution" --- like it or not that seems to be the case
with
 U.S. crypto policy; they've opened the doors enough for most practical
purposes
 leaving a spectre of doubt that they may still have the "right" to control
 the use and export of future cryptographic --- and by extension *other*
software
 --- technologies).  So I understand that the international and KLIPS
patches will
 probably be "unofficial" for the foreseeable future.

 The i2c work seems like a good candidate for inclusion (since lmsensors is
*THE*
 major user of these APIs and it requires the new version.

 As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
before Linus
 includes any of those into the mainstream.  I think it is sufficient that
he's willing 
 to accommodate the LSM (security module) to provide a common interface to
all of the 
 competing kernel hardening packages.  (I think a bit of consolidation
between the 
 international crypto patch and the LIDS patches might be in order, are they
each
 defining their own versions of the common hashing and encryption
algorithms?).

 The rmap patches are the ones which I would expect to cause the most
debate.  On the
 one hand it seems that they have significant performance and robustness
benefits
 (when the system is pushed to VM pressure) on the other hand I could
understand that
 Marcelo might be VERY reluctant to make such a deep change in a "stable"
series.
 (Linus took a lot of flack for earlier 2.4 VM changes and *he's* the
benevolent
 dictator! --- one can only imagine what will happen to any mortal that
would tempt
 fate so audaciously).  (Anyway, it seems to be a non-issue since you say
that Rik
 isn't even proposing their inclusion; I guess he has just been waiting for
an appropriate
 merge point in 2.5)

 So, I just wanted to know when the (minor) unofficial patches were getting
updated.
 Actually what I'd like is a focal point, perhaps a web site like the old
"big Mama" 
 patches (that Kurt Hewig? used to maintain), which would track and merge
these collections
 of unofficial patches.

 I'll check the FOLK (folk.sourceforge.net) pages ... [click, click]
 ... O.K. those were updated for 2.4.18rc2 so I guess they'll probably be
pretty durn
 close.

 Hmmm.  It seems that I'm rambling and wasting everyone's visual bandwidth.
I'll go 
 away now.  ;)

Re: crypto (was Re: Congrats Marcelo,)

[Chris Wright]

* Dennis, Jim (jdennis@snapserver.com) wrote:
<snip>
> As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
> before Linus includes any of those into the mainstream.  I think it is
> sufficient that he's willing to accommodate the LSM (security module)
> to provide a common interface to all of the competing kernel hardening
> packages.
<snip>

You may interested to know, LIDS has been ported to LSM, which is kept
up-to-date for stable 2.4 releases, and (for those with bitkeeper) all
2.5-pres/stable.

cheers,
-chris

Re: crypto (was Re: Congrats Marcelo,)

[Francois Romieu]

Bill Davidsen <davidsen@tmr.com> :
[...]
> Given that France blocks Ebay and there are a lot more people using that,
> I don't think they would hesitate a moment. Don't get me started on this
> topic...

I'll fill the papers this WE and see what happens. It will take some 
(bounded) time of processing.

-- 
Ueimor

Re: crypto (was Re: Congrats Marcelo,)

[Bill Davidsen]

On Mon, 25 Feb 2002, Daniel Phillips wrote:

> /me thinks about the jolly fuss that would ensue if France censored Linux

Given that France blocks Ebay and there are a lot more people using that,
I don't think they would hesitate a moment. Don't get me started on this
topic...

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: crypto (was Re: Congrats Marcelo,)

[Rik van Riel]

On Wed, 27 Feb 2002, Michael H. Warfield wrote:

> 	The one major downside, right now, is that Henry and Richard
> et al, keep talking about redesigning the klips structure to fit
> in with the more recent kernels better (ala netfilter, maybe).

> FreeSWAN archives for discussions over routing and multiple tunnels
> and the ipsec{n} interfaces to see what I meam about being hobbled
> by the crufty klips interface.  Even they don't like the state
> it's in.

That's another issue with freeswan.  Nobody seems happy with
the current state of the code  ;)


regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: crypto (was Re: Congrats Marcelo,)

[Michael H. Warfield]

On Wed, Feb 27, 2002 at 06:57:24PM -0300, Rik van Riel wrote:
> On Wed, 27 Feb 2002, Michael H. Warfield wrote:
> > On Tue, Feb 26, 2002 at 07:33:50PM -0300, Rik van Riel wrote:
> > > On Tue, 26 Feb 2002, Jeff Garzik wrote:
> >
> > > > IMO it's time to get a good IPsec implementation in the kernel...
> >
> > > Where would we get one of those ?
> >
> > > The freeswan folks seem quite determined to not let any
> > > americans touch their code, so inclusion of their stuff
> > > into the kernel is out.
> >
> > 	No...  That's patently not true.
> >
> > 	They won't accept contributions from us, but we touch
> > their code all the time.  If we didn't, how would we get any testing
> > done, which they do accept from us.
> 
> > 	They won't accept contributions from US developers to their code
> > base.  That does NOT mean that they will not accept contributing the IPSec
> > kernel code to the kernel and the incorporation of klips into the kernel
> > source tree.
> 
> Wouldn't that result in the following scenario:

> 1) freeswan gets merged into the kernel

	No...  Klips gets integrated into the kernel.  Pluto and the
supporting code and utilities are user space.

> 2) davem fixes a networking thing which
>    happens to touch freeswan

	FreeSWAN consists of two pieces, klips (Kernel Level IPSec) and
pluto plus a lot of user space glue.  Let's keep them separated into
the klips portion and the non-klips portion to cut down on the
confusion here.

	Dave, fixing a network thing, would only touch klips or one of
the interfaces.  He doesn't "touch" the non-klips code at all.  If there
is a user-space interface change, it's up to the FreeSWAN gang to
"touch" the user space code in the scripts and in pluto.  Dave doesn't
touch the user space stuff.

> 3) the freeswan developers don't take davem's
>    fix into their tree

	Once klips is in the kernel tree, it's no longer in their tree
other than code for legacy versions which lack integrated klips.
Changes or fixes to klips get submitted to the kernel sources for
the integrated versions and they become maintainers for that portion
of the kernel tree.  Their contribtutions come this way into the klips
sources in the kernel tree, not the other way around.

> 4) the next patch by the freeswan people doesn't
>    apply to what's in the kernel

	The subject on the FreeSWAN list has been targeted at getting
the klips code out of FreeSWAN and into the kernel so the only changes
or patches they make are changes against the code in the kernel outside
of the legacy kernel versions.

	Last I understood them to say, they agree that they have no
control over the incorporation of klips into the kernel and they
seem to have no problem contributing code which is used by and integrated
into software by US developers.  They just can't accept code FROM
US developers.  That implies that once klips, and only klips, is
integrated into the kernel, both parties contribute changes to that
module while the FreeSWAN developers manage their user space utilities
and code while accepting no contributions from the US developers.

> Somehow this scenario doesn't seem like it would make
> the ipsec implementation very maintainable.

	It should actually make it MORE maintainable and more installable.
If klips is in the kernel then they don't have to worry about patching
the kernel just to install FreeSWAN.  Then they can take pluto and all
the associated support stuff and roll it into a user space application
package or and rpm that can simply be agregated with the distributions.
They are even moving in that direction now by separating the builds
so that the kernel level code and pluto no longer share libraries or
common sources.  That's enabled some people to build freeswan rpms
for the user space stuff now as long as the kernel gets patched
for klips.

	The one major downside, right now, is that Henry and Richard
et al, keep talking about redesigning the klips structure to fit
in with the more recent kernels better (ala netfilter, maybe).  They've
announced some design specs and I suspect that they would rather
see the newer version of klips in the kernel tree than the crufty
version that we are hobbled with in FreeSWAN right now.  Search the
FreeSWAN archives for discussions over routing and multiple tunnels
and the ipsec{n} interfaces to see what I meam about being hobbled
by the crufty klips interface.  Even they don't like the state
it's in.

> Maybe it would be better to use what the usagi people
> are building, just to have an easier maintainable system?

> regards,
> 
> Rik
> -- 
> "Linux holds advantages over the single-vendor commercial OS"
>     -- Microsoft's "Competing with Linux" document
> 
> http://www.surriel.com/		http://distro.conectiva.com/

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: crypto (was Re: Congrats Marcelo,)

[Rik van Riel]

On Wed, 27 Feb 2002, Michael H. Warfield wrote:
> On Tue, Feb 26, 2002 at 07:33:50PM -0300, Rik van Riel wrote:
> > On Tue, 26 Feb 2002, Jeff Garzik wrote:
>
> > > IMO it's time to get a good IPsec implementation in the kernel...
>
> > Where would we get one of those ?
>
> > The freeswan folks seem quite determined to not let any
> > americans touch their code, so inclusion of their stuff
> > into the kernel is out.
>
> 	No...  That's patently not true.
>
> 	They won't accept contributions from us, but we touch
> their code all the time.  If we didn't, how would we get any testing
> done, which they do accept from us.

> 	They won't accept contributions from US developers to their code
> base.  That does NOT mean that they will not accept contributing the IPSec
> kernel code to the kernel and the incorporation of klips into the kernel
> source tree.

Wouldn't that result in the following scenario:

1) freeswan gets merged into the kernel

2) davem fixes a networking thing which
   happens to touch freeswan

3) the freeswan developers don't take davem's
   fix into their tree

4) the next patch by the freeswan people doesn't
   apply to what's in the kernel


Somehow this scenario doesn't seem like it would make
the ipsec implementation very maintainable.

Maybe it would be better to use what the usagi people
are building, just to have an easier maintainable system?

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: crypto (was Re: Congrats Marcelo,)

[Michael H. Warfield]

On Tue, Feb 26, 2002 at 07:33:50PM -0300, Rik van Riel wrote:
> On Tue, 26 Feb 2002, Jeff Garzik wrote:

> > IMO it's time to get a good IPsec implementation in the kernel...

> Where would we get one of those ?

> The freeswan folks seem quite determined to not let any
> americans touch their code, so inclusion of their stuff
> into the kernel is out.

	No...  That's patently not true.

	They won't accept contributions from us, but we touch
their code all the time.  If we didn't, how would we get any testing
done, which they do accept from us.

	Also, several of them have stated on several occasions (this is
the prerequisite religious war that pops up every few months) that
they have no say in what other people do with the code (subject to the
license of course) and that inclusion of klips in the mainline kernel
would be beyond their control, yeah or nay.  Klips is the ONLY part
of freeswan that would go in the kernel.  Pluto (IKE) is the user
space part.

	They won't accept contributions from US developers to their code
base.  That does NOT mean that they will not accept contributing the IPSec
kernel code to the kernel and the incorporation of klips into the kernel
source tree.

> Do you know of a nice ipsec implementation we could use?

	Yes.  FreeSWAN.  And the FreeSWAN developers have as much as said so.

> Rik
> -- 
> "Linux holds advantages over the single-vendor commercial OS"
>     -- Microsoft's "Competing with Linux" document
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Re: crypto (was Re: Congrats Marcelo,)

[Francois Romieu]

Robert Love <rml@tech9.net> :
[...]
> One thing I've heard in the past is "Yes, the US is safe now wrt
> encryption but <country> is not" -- and I've seen country=France,etc
> i.e. (self) important places.

The first crypto-distributing site in France will have to fill some
papers and wait a fixed amount of time to know whether is request is
dismissed (I already filled these once, it doesn't suck *that* much).
After that, the end-user won't experience any real problem. The question
boils down to "Are you a crypto provider or an end-user ?".

-- 
Ueimor - just waiting to see the proof-of-concept "crypto in 2.5" patch.

Re: crypto (was Re: Congrats Marcelo,)

[Chris Wright]

* Dennis, Jim (jdennis@snapserver.com) wrote:
> 
>  Yes, I had read that.  Do you know of any effort to consolidate the 
>  crypto libs in LIDS, patch-int, and FreeS/WAN KLIPS?

Sorry, I am not aware of such an effort.  You'd have to contact the LIDS
team, or the other projects you mentioned.  I'm just involved with the LSM
side ;-)

cheers,
-chris

RE: crypto (was Re: Congrats Marcelo,)

[Dennis, Jim]

 


> * Dennis, Jim (jdennis@snapserver.com) wrote:
> <snip>
>> As for LIDS, grsecurity, etc: I suspect it will be a cold day in hell
>> before Linus includes any of those into the mainstream.  I think it is
>> sufficient that he's willing to accommodate the LSM (security module)
>> to provide a common interface to all of the competing kernel hardening
>> packages.
> <snip>

> You may interested to know, LIDS has been ported to LSM, which is kept
> up-to-date for stable 2.4 releases, and (for those with bitkeeper) all
> 2.5-pres/stable.

> cheers,
> -chris

 Yes, I had read that.  Do you know of any effort to consolidate the 
 crypto libs in LIDS, patch-int, and FreeS/WAN KLIPS?  I'd like to think 
 that they can be maintained more efficiently and result in lower overhead
 and integration effort if the core crypto algorithms are consolidated
 among those three.

 (I remember someone found three? or four? different implementations of the
 same checksum code in the mainstream kernel a couple of years ago; I hope
 that's been fixed long since).

 (Any flames about my armchair coaching and pointed suggestions that I
 get in there and help with this are welcome --- off the list! I won't take 
 offense, I just don't want to burden everyone else's mailbox with that).

Re: crypto (was Re: Congrats Marcelo,)

[Rik van Riel]

On Tue, 26 Feb 2002, Jeff Garzik wrote:

> IMO it's time to get a good IPsec implementation in the kernel...

Where would we get one of those ?

The freeswan folks seem quite determined to not let any
americans touch their code, so inclusion of their stuff
into the kernel is out.

Do you know of a nice ipsec implementation we could use?

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: crypto (was Re: Congrats Marcelo,)

[Robert Love]

On Tue, 2002-02-26 at 16:40, arjan@fenrus.demon.nl wrote:

> loopback mount crypto. you want the actual crypts in kernel to avoid 2
> context switches per block you read.

Oh, yes, indeed -- encrypted filesystems.  Then the issue is resolving
the various international concerns.

	Robert Love

Re: crypto (was Re: Congrats Marcelo,)

[arjan]

In article <1014759355.1109.31.camel@phantasy> you wrote:
> Besides IPsec, what crypto is there for the kernel?  I've never really
> understood what "crypto in the kernel means" since it all should be a
> userspace thing.

loopback mount crypto. you want the actual crypts in kernel to avoid 2
context switches per block you read.

Re: crypto (was Re: Congrats Marcelo,)

[Robert Love]

On Tue, 2002-02-26 at 16:15, Jeff Garzik wrote:

> I would -love- to see crypto in the mainstream kernel.  Distribution of
> crypto software on kernel.org has been OK for a while now.
> 
> Who knows what the kerneli guys, freeswan, etc. guys think.
> 
> IMO it's time to get a good IPsec implementation in the kernel...

Besides IPsec, what crypto is there for the kernel?  I've never really
understood what "crypto in the kernel means" since it all should be a
userspace thing.

Except IPsec, of course, and adding Freeswan would be a Good Thing. 
Freeswan people?

One thing I've heard in the past is "Yes, the US is safe now wrt
encryption but <country> is not" -- and I've seen country=France,etc
i.e. (self) important places.

	Robert Love

crypto (was Re: Congrats Marcelo,)

[Jeff Garzik]

Andreas Dilger wrote:
> On Feb 26, 2002  12:38 -0800, Dennis, Jim wrote:
> >  Now I need to know about the status of several unofficial patches:

> >       i2c
> >       Crypto
> >       FreeS/WAN KLIPS
> >       LIDS
> 
> No idea.

I would -love- to see crypto in the mainstream kernel.  Distribution of
crypto software on kernel.org has been OK for a while now.

Who knows what the kerneli guys, freeswan, etc. guys think.

IMO it's time to get a good IPsec implementation in the kernel...

	Jeff




-- 
Jeff Garzik      | "UNIX enhancements aren't."
Building 1024    |           -- says /usr/games/fortune
MandrakeSoft     |

Re: crypto (was Re: Congrats Marcelo,)

[Daniel Phillips]

On February 26, 2002 10:47 pm, Robert Love wrote:
> On Tue, 2002-02-26 at 16:40, arjan@fenrus.demon.nl wrote:
> 
> > loopback mount crypto. you want the actual crypts in kernel to avoid 2
> > context switches per block you read.
> 
> Oh, yes, indeed -- encrypted filesystems.  Then the issue is resolving
> the various international concerns.

I'd say, just put it in and let them resolve themselves.  If that bothers
China for example they can make their own censo^H^H^H^H^H edited tree,
they have their own homegrown Linux distribution.  I think they'll just
let it go.  Really, Linux is not going to get banned from any undemocratic
countries, it's too useful.

The governments of democratic countries such as France will not object, or
if they do then they will end up being severely larted by their own
citizens, that's a fight they can't possibly win.

/me thinks about the jolly fuss that would ensue if France censored Linux

-- 
Daniel