linux-kernel - Re: The Linux Staging tree, what it is and is not.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090320105556.4375176d@lxorguk.ukuu.org.uk>
Date:	Fri, 20 Mar 2009 10:55:56 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Robert Schwebel <r.schwebel@...gutronix.de>
Cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	Greg KH <greg@...ah.com>, linux-kernel@...r.kernel.org,
	daniel.krueger@...tec-electronic.com,
	Michael Olbrich <mol@...gutronix.de>,
	Wolfram Sang <wsa@...gutronix.de>,
	Marc Kleine-Budde <mkl@...gutronix.de>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: The Linux Staging tree, what it is and is not.

> > - Security
> 
> For industrial I/O? We are talking about transportation of analog and
> digital I/O, relais, ADC input etc. The only part that I'd consider
> security related is tunnel traffic; EPL and EtherCAT have the

Maybe in your case but if that analogue I/O controls parts of a power
plant or weapons system you really really don't want a worm or trojan
getting involved with it.

> > - Sharing the device/interconnect
> 
> Sharing the device works also with userspace, because the device is a
> network card and the interface is raw ethernet frames. What do you mean
> with interconnect?

Load two user space fieldbus stacks on the same network card (remembering
this could be done by accident)

> > - Real time prioritisation
> 
> Would be done by giving the kernel task (with threaded interrupts) or
> userspace task the right POSIX relatime priorities, so I don't see a
> difference here.

There may be multiple user space tasks with differing priorities beyond
the message priority. That in turn means you want them to have different
priorities to the scheduler which means you want them to be different
processes really.

> Don't tell that to the industrial networking people - they are very
> proud of the fact that they use a "standardized application API", so
> even the fanciest and newest industrial ethernet technologies are based
> on that legacy wart objdict, and it is officially considered to be a
> *feature*.

It's a standard yes, but so once was the horse and cart.

> then you can put the whole stack into userspace. If kernel, we would
> need an objdict API to userspace...?

It depends where you split the stack between kernel and user space. There
needs to be enough in the kernel to allow reasonably efficient
multi-process models but that can be a small part of the stack. The
Appletalk stack is a good example. Appletalk has a single address/port
system for all higher level protocols and the higher level protocols
don't interact much with each other. It's actually very elegant in that
way. One result of this is that the AF_APPLETALK kernel stack deals only
with low level packet routing and delivery. It doesn't have to care about
higher stuff to provide the needed separation and sharing. IP by
comparison has all sorts of interactions, multiple port addressing
schemes and ICMP interactions which mean the kernel has to hold the
entire TCP and UDP layers.

> One thing that has to be considered is that messages often have to be
> handled fast and under realtime constraints; for example, it must be
> possible to hook up the userspace to certain changes in the objdict.
> Something like:

One model would be

kernel demux by objdict id -> forwards packet to the right user

a completely and gloriously insane one might be to have the objdict in
mmap space as you suggest but with a futex on each objdict entry.

> Note that what they are doing is to use the objdict as a binary config
> space (think registers) to configure the whole network workflow; so if

I tend to think of it as a rather peculiar shared event space - much like
the device end of SNMP. I guess we should be thankful for small mercies
that it wasn't invented today and using XML ;)

None of which is to say that an entirely userspace stack might not be the
right model, but there are distinct appeals to the kernel doing some of
the demux work and separation of stuff.

I shall be interested to see what turns out best as there are other
busses where the design really expects to set up states and the stack to
do regular repeating.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/