 |
|
| Linux Forum Index » Linux Development - System » x86 protection rings... |
|
Page 1 of 1 |
|
| Author |
Message |
| A... |
 Posted: Mon Sep 14, 2009 3:13 am |
|
|
|
Guest
|
Hi all,
I gather that Windows has traditionally loaded other companies'
drivers in
Ring 0 on the x86 architecture, and that this inclusion of
less than perfectly tested driver code is one major reason for
the BSOD or blue screen of death phenomenon of years past,
which seems quite rare nowadays.
My question is, in the case of Linux, are the drivers not also
loaded into Ring 0? I suppose that the ones compiled into
the kernel definitely are, but what about the loaded modules?
And what is the impact on kernel stability?
And what is the plan to improve kernel stability?
Thanks. |
|
|
| Back to top |
|
|
|
| André Gillibert... |
| Posted: Mon Sep 14, 2009 8:21 am |
|
|
|
Guest
|
A <questioner_x at (no spam) yahoo.com> wrote:
Quote: Hi all,
I gather that Windows has traditionally loaded other companies'
drivers in
Ring 0 on the x86 architecture, and that this inclusion of
less than perfectly tested driver code is one major reason for
the BSOD or blue screen of death phenomenon of years past,
which seems quite rare nowadays.
My question is, in the case of Linux, are the drivers not also
loaded into Ring 0? I suppose that the ones compiled into
the kernel definitely are, but what about the loaded modules?
Yes, drivers, including loaded modules, are run in ring 0 on x86.
Quote: And what is the impact on kernel stability?
A kernel driver may corrupt the kernel memory, or crash the system.
Quote: And what is the plan to improve kernel stability?
A few drivers are in user space (FUSE drivers, parts of printer drivers with CUPS, some evdev user-space input drivers), but Linux isn't going become a micro-kernel, unless things really change very much.
Use Google to see Linus' opinion about micro-kernels.
--
André Gillibert |
|
|
| Back to top |
|
|
|
| Rainer Weikusat... |
| Posted: Mon Sep 14, 2009 8:43 am |
|
|
|
Guest
|
A <questioner_x at (no spam) yahoo.com> writes:
Quote: I gather that Windows has traditionally loaded other companies'
drivers in Ring 0 on the x86 architecture, and that this inclusion of
less than perfectly tested driver code is one major reason for
the BSOD or blue screen of death phenomenon of years past,
which seems quite rare nowadays.
This used to be claimed and judging from the few bits of 'proprietary'
driver code I have seen (because of work) I consider this to be a
credible claim.
Quote: My question is, in the case of Linux, are the drivers not also
loaded into Ring 0? I suppose that the ones compiled into
the kernel definitely are, but what about the loaded modules?
UNIX(*) and similar systems have always only used two 'hardware
privilege levels', 'running in kernel mode' (and 'allowed to do
everything') or 'running in user mode' (and 'must utilize the kernel
for privileged operations').
Quote: And what is the impact on kernel stability?
Reportedly, proprietary closed-source drivers, mainly having been
'engineered' to minimze software cost for device makers, are as bad on
Linux as elsewhere. This is not much of a problem for drivers where
source code is available. These usually don't share the structural
problems of their proprietary bethren (support as many different
device as anyhow possible using a single code base) and while they are
not necessarily initially less buggy, more people can fix or at least
help with fixing these issues.
Quote: And what is the plan to improve kernel stability?
Insofar the kernel(s) I am running exhibit behaviour I really cannot
tolerate, I change them. |
|
|
| Back to top |
|
|
|
| Tim Roberts... |
| Posted: Wed Sep 16, 2009 12:14 am |
|
|
|
Guest
|
A <questioner_x at (no spam) yahoo.com> wrote:
Quote:
I gather that Windows has traditionally loaded other companies'
drivers in
Ring 0 on the x86 architecture, and that this inclusion of
less than perfectly tested driver code is one major reason for
the BSOD or blue screen of death phenomenon of years past,
which seems quite rare nowadays.
As a professional driver writer, I cannot let this go without comment.
Kernel drivers are by far the most common cause of crashes, both on Windows
and Linux. In both operating systems, kernel code is trusted code. If you
are in ring 0, you have no limits. However, the blue screens of the late
1990s were as much about Microsoft kernel code as it was about third party
drivers.
You may have seen the dialog that pops up after a Windows crash that offers
to send the crash info to Microsoft. (In general, you should always say
"yes" if you don't know the cause.) They actually do process all of those
crash reports, which were coming in at a rate of nearly 1 per second in the
early part of the century. They discovered that nearly 1/3 of those
crashes were caused by video drivers.
In order to get the "Windows Hardware Quality Lab" signature, and hence get
listed in the Windows Driver Library, the vendor has to agree to receive
and address any crash reports that are traced to their driver. That single
step has actually improved the Windows BSOD situation enormously.
However, there is no such thing as "perfectly tested driver code."
Quote: My question is, in the case of Linux, are the drivers not also
loaded into Ring 0? I suppose that the ones compiled into
the kernel definitely are, but what about the loaded modules?
For now, they have to be. In the current design, you must be in ring 0 to
handle interrupts.
Quote: And what is the impact on kernel stability?
That's a hard question to answer, since there is at present no alternative.
"Impact" compared to what? Linux could use ring 1 for "less trusted kernel
code", but that would require a significant change in both code and
philosophy.
Quote: And what is the plan to improve kernel stability?
Do you find the Linux kernel's stability to be unacceptable?
--
Tim Roberts, timr at (no spam) probo.com
Providenza & Boekelheide, Inc. |
|
|
| Back to top |
|
|
|
| Rainer Weikusat... |
| Posted: Wed Sep 16, 2009 4:06 am |
|
|
|
Guest
|
Tim Roberts <timr at (no spam) probo.com> writes:
Quote: A <questioner_x at (no spam) yahoo.com> wrote:
I gather that Windows has traditionally loaded other companies'
drivers in
Ring 0 on the x86 architecture, and that this inclusion of
less than perfectly tested driver code is one major reason for
the BSOD or blue screen of death phenomenon of years past,
which seems quite rare nowadays.
As a professional driver writer, I cannot let this go without comment.
Kernel drivers are by far the most common cause of crashes, both on Windows
and Linux. In both operating systems, kernel code is trusted code. If you
are in ring 0, you have no limits. However, the blue screens of the late
1990s were as much about Microsoft kernel code as it was about third party
drivers.
You may have seen the dialog that pops up after a Windows crash that offers
to send the crash info to Microsoft. (In general, you should always say
"yes" if you don't know the cause.) They actually do process all of those
crash reports, which were coming in at a rate of nearly 1 per second in the
early part of the century. They discovered that nearly 1/3 of those
crashes were caused by video drivers.
In order to get the "Windows Hardware Quality Lab" signature, and hence get
listed in the Windows Driver Library, the vendor has to agree to receive
and address any crash reports that are traced to their driver. That single
step has actually improved the Windows BSOD situation enormously.
However, there is no such thing as "perfectly tested driver code."
But wait, it gets better. Code paths are combinatorial. In our
example above, the error variable may have been initialized
earlier--let's say by a similar code snippet whose predicate
("system call failure") was false (meaning no error
occurred). The following example, which is patently bad code
that would not pass any kind of code review anyway, shows how
easy it is for simple things to become complicated:
1. if (connect(s, &sa, &sa_len) == -1)
2. error++;
3. else
4. error = 0;
5. if (read(s, buf, sizeof buf) == -1)
6. error++;
7. else
8. error = 0;
There are now four code paths to test:
1. lines 1-2-5-6.
2. lines 1-2-5-8.
3. lines 1-4-5-6.
4. lines 1-4-5-8.
http://oreilly.com/catalog/opensources/book/vixie.html
Now, for the sake of example (and this is a real-world example),
assume a driver for something like four or five different revisions of
a particular MAC, supposed to cooperate with and work around the bugs
of something like ten different PHYs, supposed to work with eleven
different operating systems, could you imagine a reason why this
particular driver was 'less than perfectly tested'? |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Fri Dec 11, 2009 7:19 am
|
|