I have become quite familar with L4/x86 Reference manual and
L4 User manual (for MIPS) but I think they don't give
enough information about
designing and writing programs on to the L4 architecture.
In my opinion they are
a bit unclear and incomplete.
Therefore I'd like to ask some questions on that subject.
What kind of address space do the initial servers get? I
know that sigma0 has the
complete physical address space idempotently mapped but
what about others?
What pages do they have …
[View More]initially mapped?
I have understood that the kernel isn't able to free memory
it has allocated.
Is that true?
How is the destination address of an intercepted IPC
delivered to the chief?
What is sigma1? What should it do?
Is sigma0 able to map memory above 0x40000000? How?
What happens when the version numbers of a task are used
up? Could they be reused?
Could tasks donate interrupts like they can donate task
numbers?
Thanks for everyone who bothers to answer.
[View Less]
John Nagle <nagle(a)animats.com> writes:
> Once I/O flexpages are in, RMGR will be able to issue access to
> device space byte by byte.
That's right.
> It can connect up interrupts to drivers now.
Small correction: L4 currently has no interface for safely passing an
interrupt assignment. All Rmgr can do when a driver asks for an
interrupt is release its attachment so that the driver can attach.
This opens a time window for a malicious process racing with the
driver to …
[View More]steal the attachment.
> The remaining big security problem is DMA.
Of course, DMA will be restricted to processes having access to the
ports controlling the DMA controller.
> In most systems, device drivers are given total access to DMA
> controllers. Could that be avoided, with a trusted process that
> handles the DMA controllers at the request of the device drivers?
>
> I'm going to concentrate on PCI bus issues, since ISA is
> on the way out and SCSI, USB, and IEEE-1394 devices usually work
> through a PCI controller.
>
> For most devices, DMA is performed by DMA controllers in the
> core chipset (such as the Intel 82810), not by the peripherals
> themselves. It's seems to be possible to disable the ability of a
> PCI device to become a bus master without disabling the ability
> of the DMA controllers to execute memory and PCI bus cycles,
> at least with the more modern core chipsets.
>
> So it ought to be possible to have a trusted process that
> handles DMA and deals with the memory mapping issues. This
> process would be used by device drivers that need DMA. Drivers
> would not have access to the DMA controllers directly and would
> be untrusted.
Yes, all that is correct. A different solution would be to simply
trust device drivers also.
> There's the related issue of hardware discovery, or
> "plug and play". Something is needed at startup to discover
> all the hardware, build the hardware tree, and parcel out
> hardware resources to drivers. What's planned in that area?
We plan to do all this in a device-managing component.
As a start, Uwe Dannowski already has added some enhancements to Rmgr
that discovers PCI devices and remaps their memory-mapped I/O ports so
that only one device has ports in a given high-memory superpage,
enabling access control to memory-mapped I/O ports for device drivers.
However, I think his changes are currently not available publicly. :(
Other than that, not much has been done so far in this area. All
drivers currently contain their own PCI-device-discovery code.
> Is this consistent with the thinking of the L4/Fiasco/Drops
> groups? If not, is there something wrong here?
I think you ate pretty much inline with our thinking.
Regards,
Michael
--
hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de
http://home.pages.de/~hohmuth/
[View Less]
THIS IS A ONE TIME MAILING
You were sent this email because it was believed it would benefit you in some way
If you do not want this email - simply delete it -
TEST YOUR SATELLITE CHANNELS - DO THEY WORK? TEST THEM AND SEE
Your satellite receiver - if you have Direct Tv - came with a little credit card sized programming card known as a smart card. We can, for testing purposes only, program your card to receive any and all channels offered by your satellite company without you having to …
[View More]pay an additional monthly fee. You will receive blacked out sporting events, pay per views, premium channels and unlimited, unrestricted access to ANY channel offered by your satellite company after we program your card. We can only program H cards. These are the cards that say "DSS ACCESS CARD" on them and they are blue. We can NOT program Dish Network cards.
This service is provided for testing purposes only. To receive an order form and for more informaton - Please Call 1-770-621-5852 (24hours a day, 7 days a week).
[View Less]
David Welch <david.welch(a)st-edmund-hall.oxford.ac.uk> writes:
> The cvs server at os.inf.tu-dresden.de seems to be down, is this a
> temporary problem, or has cvs access been moved or removed?
Temporary problem -- sorry for the downtime. It's back up now.
Michael
--
hohmuth(a)innocent.com, hohmuth(a)inf.tu-dresden.de
http://home.pages.de/~hohmuth/
A key concept of L4 is that device drivers should be outside the
kernel, and not have privileges that allow them to crash the system.
This requires support outside the kernel that isn't yet present.
I'm writing this to ask some questions about how that will be
architected.
Once I/O flexpages are in, RMGR will be able to issue access to
device space byte by byte. It can connect up interrupts to drivers
now. The remaining big security problem is DMA.
In most systems, device drivers …
[View More]are given total access to DMA
controllers. Could that be avoided, with a trusted process that
handles the DMA controllers at the request of the device drivers?
I'm going to concentrate on PCI bus issues, since ISA is
on the way out and SCSI, USB, and IEEE-1394 devices usually work
through a PCI controller.
For most devices, DMA is performed by DMA controllers in the
core chipset (such as the Intel 82810), not by the peripherals
themselves. It's seems to be possible to disable the ability of a
PCI device to become a bus master without disabling the ability
of the DMA controllers to execute memory and PCI bus cycles,
at least with the more modern core chipsets.
So it ought to be possible to have a trusted process that
handles DMA and deals with the memory mapping issues. This
process would be used by device drivers that need DMA. Drivers
would not have access to the DMA controllers directly and would
be untrusted.
There's the related issue of hardware discovery, or
"plug and play". Something is needed at startup to discover
all the hardware, build the hardware tree, and parcel out
hardware resources to drivers. What's planned in that area?
Is this consistent with the thinking of the L4/Fiasco/Drops
groups? If not, is there something wrong here?
John Nagle
Animats
www.animats.com
[View Less]
Hello, after aplying a patch sent by Jean (thanks Jean!) everything seemed
to work just fine. Except for one thing. After restarting the stopped
thread, with l4_thread_ex_regs, if main() would try to do a getchar() (for
instance) the re-started thread would stop ... if I change the
getchar() for a for(;;); everyting works just fine.
And theres one more thing, please if someone can tell me if this behaviuor
is correct or not, when stopping a thread w/l4_thread_ex_regs lets say we
stop it by …
[View More]changing its eip to a func.
always_release() {
for(;;)
l4_thread_switch(L4_NIL_ID);
}
If one were to leave the original esp, when re-starting the original
thread, by changing its eip to the original func., all the values
contained in the stack were to be clobbered ... now ... is this normal
? should l4_thread_switch() change the values in the stack ? (of course, a
workaround to this is to declare a char release_stack[] and use it when
stopping the thread as its new stack).
Ciao.
Cervi~no Ulises <kermit(a)tower.com.ar> <ulises(a)rosario.linux.org.ar>
...............................................................................
"Contrary to popular opinion, Unix is user friendly, It just happens to be
very selective about who it makes friends with."
[View Less]
-----BEGIN PGP SIGNED MESSAGE-----
Hello,
I hope someone can tell me why the following source produces an
error (trapno 14, error 5):
------------------------------------
class BaseClass
{
public:
virtual void print() {
printf("BaseClass::print()\n");
};
};
class DerivedClass : public BaseClass
{
public:
virtual void print() {
printf("DerivedClass::print()\n");
};
};
DerivedClass dc;
void main(void)
{
BaseClass *bc = &dc;
bc->print();
}
----------------------
…
[View More]If dc is defined inside main(), everything works fine.
Chris
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Christian Stueble............stueble(a)ls6.cs.uni-dortmund.de
PubKey[BF7104F5].......fp=8678C5D3CAD9CD8C F1DDB8EC202F116A
To be or not to be is true... (apocrypha of George Boole)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: Mqyve75goky7Nb6fefYC/Sh3qq9PuiJi
Comment:
iQCVAwUBOH3OA/yJjJy/cQT1AQEzOQQAut8lc3ns0EgZiQc80OgiKjlgnLv9g4Np
bOdvfgxqspDkUqV6j/D/w0I1tJc3QAwLh8EsF4t6K27dd3yqJN2JVEnvud/7wNGh
as2+1S1gqhV6k6dttkY5rfPy+epp/e8ZM5jmhFiS0H/HG+F6Vq+wTAm1f3DnWpoX
a1mRhzHjZ+g=
=fR1c
-----END PGP SIGNATURE-----
[View Less]
A first version of a document entitled "Inside L4/MIPS" containing
annotated L4 source code is available from
http://www.cse.unsw.edu.au/~disy/L4/index.html. It is still incomplete,
so far covering kernel data structures, exception handling and IPC.
Any feedback/suggestions/corrections/additions are highly appreciated.
Gernot
--
Gernot Heiser ,--_|\ School of Computer Sci. & Engin.
Phone: +61 2 9385 5156 / \ The University of NSW
Fax: +61 2 9385 5533 \_,-…
[View More]-._* Sydney, Australia 2052
E-mail: gernot(a)unsw.edu.au v http://www.cse.unsw.edu.au/~gernot
PGP fingerprint: 94 1E B8 28 25 FD 7C 94 20 10 92 E5 0B FF 39 8F
[View Less]
Hello, I have the following scenario were everything goes just wrong.
I have only one task running, which creates a thread using
l4_thread_ex_regs ... after a 4 secs. sleep using l4_ipc_receive it
changes the eip value of the thread to a piece of code that reads:
void always_release()
{
for(;;)
l4_thread_switch(L4_NIL_ID);
}
After doing this the main thread (# 0) tries to wait 4 secs. using
l4_ipc_receive again and then change the eip of the created thread to its
old eip. The problem is …
[View More]that the main thread never wakes up. I mean, after
the 4 secs. have passed ... the main thread is still blocked. Are we in
prescence of a bug ?
Cheers.
Cervi~no Ulises <kermit(a)tower.com.ar> <ulises(a)rosario.linux.org.ar>
...............................................................................
"Contrary to popular opinion, Unix is user friendly, It just happens to be
very selective about who it makes friends with."
[View Less]