* Re: my review of the Device Driver Hardening Design Spec
[not found] <mailman.1032587460.6299.linux-kernel2news@redhat.com>
@ 2002-09-21 12:51 ` Pete Zaitcev
2002-09-21 18:16 ` Greg KH
0 siblings, 1 reply; 11+ messages in thread
From: Pete Zaitcev @ 2002-09-21 12:51 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
> - actually, what do any of these CONFIG_ options do, and why
> would someone not want the CONFIG_DRIVER_ROBUST to be always
> enabled?
Probably performance blows when it is enabled.
> In summary, I think that a lot of people have spent a lot of time in
> creating this document, and the surrounding code that matches this
> document. I really wish that a tiny bit of that effort had gone into
> contacting the Linux kernel development community, and asking to work
> with them on a project like this. Due to that not happening, and by
> looking at the resultant spec and code, I'm really afraid the majority
> of that time and effort will have been wasted.
Eek. They never mentioned any code before now. In fact they
explicitly said they weren't going to code before the spec
was ready.
-- Pete
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 12:51 ` my review of the Device Driver Hardening Design Spec Pete Zaitcev
@ 2002-09-21 18:16 ` Greg KH
2002-09-21 21:52 ` Francois Romieu
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2002-09-21 18:16 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel, hardeneddrivers-discuss, cgl_discussion
On Sat, Sep 21, 2002 at 08:51:15AM -0400, Pete Zaitcev wrote:
>
> > In summary, I think that a lot of people have spent a lot of time in
> > creating this document, and the surrounding code that matches this
> > document. I really wish that a tiny bit of that effort had gone into
> > contacting the Linux kernel development community, and asking to work
> > with them on a project like this. Due to that not happening, and by
> > looking at the resultant spec and code, I'm really afraid the majority
> > of that time and effort will have been wasted.
>
> Eek. They never mentioned any code before now. In fact they
> explicitly said they weren't going to code before the spec
> was ready.
Oh, there's lots of code:
A "hardened" binary kernel driver:
http://unc.dl.sourceforge.net/sourceforge/hardeneddrivers/sampledriver-0.1-1.i386.rpm
(um people, why a binary? Where's the source for this?)
Some header files:
http://unc.dl.sourceforge.net/sourceforge/hardeneddrivers/ddhardening_headerfiles.tar.gz
A bunch of diagnostics code:
http://linux-diag.sourceforge.net/code/cpu_affinity-v0.2.1.tar.gz
http://linux-diag.sourceforge.net/code/pmem-0.2.1.tar.gz
http://linux-diag.sourceforge.net/code/crms-0.1.1.tar.gz
And a bunch of resource monitoring code:
http://sourceforge.net/project/showfiles.php?group_id=54710
CG people, are you wanting any of this code to be in the main kernel?
If so, why have you not submitted it to anyone yet? And why did you
write any code before the spec was ready if you said you were not going
to do that?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 18:16 ` Greg KH
@ 2002-09-21 21:52 ` Francois Romieu
2002-09-21 22:02 ` Mr. James W. Laferriere
2002-09-21 22:42 ` Greg KH
0 siblings, 2 replies; 11+ messages in thread
From: Francois Romieu @ 2002-09-21 21:52 UTC (permalink / raw)
To: linux-kernel; +Cc: hardeneddrivers-discuss
[Cc list trimmed]
Greg KH <greg@kroah.com> :
[...]
> Oh, there's lots of code:
> A "hardened" binary kernel driver:
> http://unc.dl.sourceforge.net/sourceforge/hardeneddrivers/sampledriver-0.1-1.i386.rpm
> (um people, why a binary? Where's the source for this?)
In the cvs. See:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hardeneddrivers/sample_driver/src/
--
Ueimor
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 21:52 ` Francois Romieu
@ 2002-09-21 22:02 ` Mr. James W. Laferriere
2002-09-21 22:17 ` Francois Romieu
2002-09-21 22:42 ` Greg KH
1 sibling, 1 reply; 11+ messages in thread
From: Mr. James W. Laferriere @ 2002-09-21 22:02 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, hardeneddrivers-discuss
Hello Francois , A suggestion for Documentation . Please produce
output of Windows docs into non-propitary formats .
txt , pfd , ps , ... Tia , JimL
On Sat, 21 Sep 2002, Francois Romieu wrote:
> [Cc list trimmed]
>
> Greg KH <greg@kroah.com> :
> [...]
> > Oh, there's lots of code:
> > A "hardened" binary kernel driver:
> > http://unc.dl.sourceforge.net/sourceforge/hardeneddrivers/sampledriver-0.1-1.i386.rpm
> > (um people, why a binary? Where's the source for this?)
>
> In the cvs. See:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hardeneddrivers/sample_driver/src/
>
> --
> Ueimor
> -
> 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/
>
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 22:02 ` Mr. James W. Laferriere
@ 2002-09-21 22:17 ` Francois Romieu
2002-09-21 22:35 ` Mr. James W. Laferriere
0 siblings, 1 reply; 11+ messages in thread
From: Francois Romieu @ 2002-09-21 22:17 UTC (permalink / raw)
To: Mr. James W. Laferriere; +Cc: linux-kernel
Mr. James W. Laferriere <babydr@baby-dragons.com> :
[...]
> Hello Francois , A suggestion for Documentation . Please produce
> output of Windows docs into non-propitary formats .
> txt , pfd , ps , ... Tia , JimL
I don't remember having written a doc in proprietary format lately.
--
Ueimor
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 22:17 ` Francois Romieu
@ 2002-09-21 22:35 ` Mr. James W. Laferriere
2002-09-21 22:37 ` Mr. James W. Laferriere
0 siblings, 1 reply; 11+ messages in thread
From: Mr. James W. Laferriere @ 2002-09-21 22:35 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel
Hello Francios , ... Hth , JimL
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hardeneddrivers/docs/DD_hardening_spec.doc
On Sun, 22 Sep 2002, Francois Romieu wrote:
> Mr. James W. Laferriere <babydr@baby-dragons.com> :
> [...]
> > Hello Francois , A suggestion for Documentation . Please produce
> > output of Windows docs into non-propitary formats .
> > txt , pfd , ps , ... Tia , JimL
> I don't remember having written a doc in proprietary format lately.
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 22:35 ` Mr. James W. Laferriere
@ 2002-09-21 22:37 ` Mr. James W. Laferriere
0 siblings, 0 replies; 11+ messages in thread
From: Mr. James W. Laferriere @ 2002-09-21 22:37 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel
Hello Francois , found the pdf of the same doc I beleive .
Tia , JimL
On Sat, 21 Sep 2002, Mr. James W. Laferriere wrote:
>
> Hello Francios , ... Hth , JimL
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hardeneddrivers/docs/DD_hardening_spec.doc
>
> On Sun, 22 Sep 2002, Francois Romieu wrote:
> > Mr. James W. Laferriere <babydr@baby-dragons.com> :
> > [...]
> > > Hello Francois , A suggestion for Documentation . Please produce
> > > output of Windows docs into non-propitary formats .
> > > txt , pfd , ps , ... Tia , JimL
> > I don't remember having written a doc in proprietary format lately.
>
> +------------------------------------------------------------------+
> | James W. Laferriere | System Techniques | Give me VMS |
> | Network Engineer | P.O. Box 854 | Give me Linux |
> | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
> +------------------------------------------------------------------+
>
> -
> 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/
>
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 21:52 ` Francois Romieu
2002-09-21 22:02 ` Mr. James W. Laferriere
@ 2002-09-21 22:42 ` Greg KH
2002-09-22 0:57 ` Andre Hedrick
1 sibling, 1 reply; 11+ messages in thread
From: Greg KH @ 2002-09-21 22:42 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, hardeneddrivers-discuss
On Sat, Sep 21, 2002 at 11:52:19PM +0200, Francois Romieu wrote:
> [Cc list trimmed]
>
> Greg KH <greg@kroah.com> :
> [...]
> > Oh, there's lots of code:
> > A "hardened" binary kernel driver:
> > http://unc.dl.sourceforge.net/sourceforge/hardeneddrivers/sampledriver-0.1-1.i386.rpm
> > (um people, why a binary? Where's the source for this?)
>
> In the cvs. See:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hardeneddrivers/sample_driver/src/
Thanks for pointing this out, I missed it.
Hm, if this is the code that the CG group is proposing for reliable
drivers, we are all in trouble. See:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/hardeneddrivers/sample_driver/src/sampledriver.h?rev=1.1.1.1
as a very small example of what not to do :)
I'd be glad to provide concrete criticism of the other files in this
directory, if I thought people would actually change their programming
style to follow what their own spec says to do...
{sigh}
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/hardeneddrivers/sample_driver/src/sampledriver_init.c?rev=1.1.1.1
contains so many examples of bad style, and real bugs...
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 22:42 ` Greg KH
@ 2002-09-22 0:57 ` Andre Hedrick
0 siblings, 0 replies; 11+ messages in thread
From: Andre Hedrick @ 2002-09-22 0:57 UTC (permalink / raw)
To: Greg KH; +Cc: Francois Romieu, linux-kernel, hardeneddrivers-discuss
#ifndef __MYDRVR_H__
#define __MYDRVR_H__
#define MYDRVR_IOCTL_MAGIC 'm'
#define MYDRVR_IOCTL_RCV _IO(MYDRVR_IOCTL_MAGIC, 0)
typedef struct _MYDRVR_CONTEXT {
unsigned long cRCV; /* number of RCV ioctls made */
unsigned long cDeviceOpen; /* device open count */
} MYDRVR_CONTEXT, *PMYDRVR_CONTEXT;
#define ZEROMEMORY(pAddr, cbSize) \
{ \
int i; \
char *d = (char *)(pAddr); \
for ( i = 0; i < (cbSize); i++, *d++ = 0 ); \
}
#endif /* __MYDRVR_H__ */
SHEESH, COULD THEY LEARN THERE IS MORE TO LIFE THAN ALL CAPS??
Sweet, that is "stick ugly"!
stick ugly : beating with a stick and it can not made any uglier than it
is presently.
Andre Hedrick
LAD Storage Consulting Group
On Sat, 21 Sep 2002, Greg KH wrote:
> On Sat, Sep 21, 2002 at 11:52:19PM +0200, Francois Romieu wrote:
> > [Cc list trimmed]
> >
> > Greg KH <greg@kroah.com> :
> > [...]
> > > Oh, there's lots of code:
> > > A "hardened" binary kernel driver:
> > > http://unc.dl.sourceforge.net/sourceforge/hardeneddrivers/sampledriver-0.1-1.i386.rpm
> > > (um people, why a binary? Where's the source for this?)
> >
> > In the cvs. See:
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hardeneddrivers/sample_driver/src/
>
> Thanks for pointing this out, I missed it.
>
> Hm, if this is the code that the CG group is proposing for reliable
> drivers, we are all in trouble. See:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/hardeneddrivers/sample_driver/src/sampledriver.h?rev=1.1.1.1
>
> as a very small example of what not to do :)
>
> I'd be glad to provide concrete criticism of the other files in this
> directory, if I thought people would actually change their programming
> style to follow what their own spec says to do...
>
> {sigh}
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/hardeneddrivers/sample_driver/src/sampledriver_init.c?rev=1.1.1.1
> contains so many examples of bad style, and real bugs...
>
> greg k-h
> -
> 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/
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: my review of the Device Driver Hardening Design Spec
2002-09-21 5:34 ` my review of the Device Driver Hardening Design Spec Greg KH
@ 2002-09-21 15:21 ` Martin J. Bligh
0 siblings, 0 replies; 11+ messages in thread
From: Martin J. Bligh @ 2002-09-21 15:21 UTC (permalink / raw)
To: Greg KH, Rhoads, Rob, linux-kernel, hardeneddrivers-discuss,
cgl_discussion
> What do I think can be salvaged? Diagnostics are a good idea, and I
> think they fit into the driver model in 2.5 pretty well. A lot of
> kernel janitoring work could be done by the CG team to clean up, and
> harden (by applying the things in section 2) the existing kernel
> drivers. That effort alone would go a long way in helping the stability
> of Linux, and also introduce the CG developers into the kernel community
> as active, helping developers. It would allow the CG developers to
> learn from the existing developers, as we must be doing something right
> for Linux to be working as well as it does :)
People with fault injection hardware are also extremely helpful
(assuming they do something useful with it). That's not something most
of the community would have access to, but the CG-type people probably
do. A couple of people who spent their full time kicking the hell out
of Sequent's fibrechannel system made a massive difference to it's
quality and reliabilty.
That's definitely something this project could help by doing ...
whatever people feel about the some of more theoretical aspects to
their work being discussed, I think few would object to some real-world
help from people tracking down and fixing existing bugs, especially in
the error handling.
M.
^ permalink raw reply [flat|nested] 11+ messages in thread
* my review of the Device Driver Hardening Design Spec
2002-09-21 1:40 [ANNOUNCE] Linux Hardened Device Drivers Project Greg KH
@ 2002-09-21 5:34 ` Greg KH
2002-09-21 15:21 ` Martin J. Bligh
0 siblings, 1 reply; 11+ messages in thread
From: Greg KH @ 2002-09-21 5:34 UTC (permalink / raw)
To: Rhoads, Rob, linux-kernel, hardeneddrivers-discuss, cgl_discussion
<sorry for the mangled header on the first send of this>
On Fri, Sep 20, 2002 at 06:40:54PM -0700, Greg KH wrote:
> Hi,
>
> I've just started to read over the published spec, and will reserve
> comment on it, and the example code you've created after I'm done
> reading it.
Ok, here's some comments on the 0.5h release of the Device Driver
Hardening Design Specification:
(I'll skip the intro, and feel good sections and get into the details
that you lay out, starting in section 2)
Section 2:
2.1:
- do NOT use /proc for driver info. Use driverfs.
- If you are using a kernel version that does not have driverfs,
put all /proc driver info under /proc/drivers, which is where
it belongs.
- Only have 1 value per file, and no binary data in the files.
- Do not put the "kernel version for which the driver was
compiled", as that _always_ much match the kernel version that
is running, so is redundant.
2.2:
- do NOT use typedef
2.5.5:
- you do not have to always check data returned from functions,
if you wrote the functions in the first place. Redundant
checking of all data within the kernel, slows things down.
Sure, some checking is good, but do not say that it is a
requirement, or no one will want to use your driver.
The majority of section 2 is very nice, it's a good list of things that
drivers should do.
Section 3:
Wow, where to start...
The Common Statistic Manager:
- why does this have to live in the kernel? It should be in
userspace, grabbing all of the data from the /proc files you
just specified in section 2.1.
POSIX event logging:
- wow, not much I can say here, that hasn't already been said
before :(
Diagnostics:
- now these are a good idea. A common subsystem that drivers
can register what kind of diagnostics they can run on their
hardware, nice.
3.1.1:
- UUIDs!!!??? You have got to be kidding. Here, for the
benefit of those who have not read this, I'll quote:
"Each subsystem, and each resource contained within each
subsystem, needs to be uniquely identified. In order to
do this a hardened driver developer shall pre-assign a
Universally Unique Identifier (UUID) as the Subsystem ID
for each subsystem, and shall provide a means to assign
a unique Resource ID string for each resource within a
subsystem."
So for every resource, a string shall be associated with it.
But that means for most resources, the string will take up more
memory than the resource itself does. Does that make sense?
It's also up to the driver to create these resource ids at
runtime and guarantee their uniqueness over the lifetime of the
kernel. How in the world can you expect every driver author to
do this? Any example code out there?
And what are these UUIDs going to be used for, ah, event
logging. Enough said.
3.2 Statistics:
You actually want every driver to support SNMP compliant
statistics groups within themselves? Why? What a bloat of a
kernel.
All of this should be done (if at all) from userspace.
3.2.5.2:
(I'm not condoning ANY of these functions or code, just trying to point out how
you should, if they were to be in the kernel, done properly.)
- do not use typedef
- struct stat_info does not need *unit, as that is already
specified in the scale field, right?
- the stat_value_t union is just a horrible abomination, don't
do that.
3.3 Diagnostics:
- not a bad idea, but some work could be done on the
implementation. Would fit in nicely with the device driver
model in 2.5. For 2.4, it would be another subsystem a driver
would register with.
3.3.3.2:
- no typedefs
- run() is horrible, you are trying to fit all kinds of possible
diagnosis into one function callback. Not a good idea.
Break the different kinds of callbacks out into different
functions. That ensures type safety, right now you are just
creating another ioctl() type mess.
3.4 Event logging:
- I'm not even going to touch this, sorry.
4: High Availability
- are you all working with the existing HA group?
4.1:
- um, what are you trying to say here. This section is
pointless. Yes we all think Hot Swap is a good idea, that's
why Linux currently supports it.
4.2:
- RAID and ethernet bonding is nice. Again, Linux already has
projects and support for these things. Why mention them?
The rest of this section is fine, and I welcome any test harnesses that
are created to do this kind of fault injection for driver testing.
5:
- Here you back-pedal on everything you said up till now. Let
me summarize what is said in these 3 paragraphs in 1 sentence:
"Yes, all these things are well and good, but don't let
them effect the currently great performance Linux has
today."
Sorry, but you can't have it both ways.
5.1:
- do NOT use #ifdef in the .c files. Only in .h files.
- why is CONFIG_DRIVER_HOTSWAP an option. What does it do that
CONFIG_HOTPLUG does not do today?
- actually, what do any of these CONFIG_ options do, and why
would someone not want the CONFIG_DRIVER_ROBUST to be always
enabled?
In summary, I think that a lot of people have spent a lot of time in
creating this document, and the surrounding code that matches this
document. I really wish that a tiny bit of that effort had gone into
contacting the Linux kernel development community, and asking to work
with them on a project like this. Due to that not happening, and by
looking at the resultant spec and code, I'm really afraid the majority
of that time and effort will have been wasted.
What do I think can be salvaged? Diagnostics are a good idea, and I
think they fit into the driver model in 2.5 pretty well. A lot of
kernel janitoring work could be done by the CG team to clean up, and
harden (by applying the things in section 2) the existing kernel
drivers. That effort alone would go a long way in helping the stability
of Linux, and also introduce the CG developers into the kernel community
as active, helping developers. It would allow the CG developers to
learn from the existing developers, as we must be doing something right
for Linux to be working as well as it does :)
Also, open specs for the hardware the CG members produce, to allow
existing kernel drivers to be enhanced (instead of having to be reverse
engineered), and new kernel drivers to be created, would also go a long
way in helping out both the CG's members and the entire Linux
community's cause of having a robust, stable kernel be achived easier.
Closed specs, and closed drivers do not help anyone.
thanks for reading this far,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2002-09-22 0:56 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.1032587460.6299.linux-kernel2news@redhat.com>
2002-09-21 12:51 ` my review of the Device Driver Hardening Design Spec Pete Zaitcev
2002-09-21 18:16 ` Greg KH
2002-09-21 21:52 ` Francois Romieu
2002-09-21 22:02 ` Mr. James W. Laferriere
2002-09-21 22:17 ` Francois Romieu
2002-09-21 22:35 ` Mr. James W. Laferriere
2002-09-21 22:37 ` Mr. James W. Laferriere
2002-09-21 22:42 ` Greg KH
2002-09-22 0:57 ` Andre Hedrick
2002-09-21 1:40 [ANNOUNCE] Linux Hardened Device Drivers Project Greg KH
2002-09-21 5:34 ` my review of the Device Driver Hardening Design Spec Greg KH
2002-09-21 15:21 ` Martin J. Bligh
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).