OSDev.org

I am attempting to make a design that will give the user complete control over the OS
what I mean is like...
a virus is made that edits the startup file(tells what apps to run when you startup) so that it runs the virus a million times, making your pc unusable; what I would want is for it to check fopen and if it is a system file(like startup) then it gives a warning in the system console(brings the console to the front and such) and asks the user "An application is attempting to modify your startup file, this could make your pc crash, if you don't trust the application then I reccommend allowing this. Would you like to allow this application to open startup.str for writing? " or something like that, and then of course having a way to disable warnings

does anyone see a problem with this?
it would also give warning on installing drivers, because I don't want an app to just be able to run and then install a virus driver



now about ring3 drivers:
I want to support ring3 drivers, supporting things like interrupt installing and port access, but also it would prevent some things such as a gpf crashing your pc(also it would enable me to control what ports can be accessed...)

also, would this work?
to get interrupt installing, possible without causing an interrupt freeze or them direct control of iret stack stuff I want to do the interrupt but set the return address of a special stub that calls whatever is used for the interrupt and then when they return then I send the EOI command to the special port would this cause any conflicts?

oh and yea I would support ring0 drivers also but not reccommended to be used unless you trust the person who made it

Hey..

For the startup file, the idea is good in my opinion, and you could also have the system check to see how many times the referenced program opens, and if it is greater then say 2, it would not open it or open it once or twice.

In addition to restricting file access...

Like the idea I had for SensoryOS, you could also prevent any application from running unless it's been installed, and prevent any application from being installed unless the user has approved it and it's digitally signed or the user is an admin. Thoughts?

That would eliminate the vast majority of the utilities I use for various things that are simple download-extract-use affairs

Jordan3 wrote: "An application is attempting to modify your startup file, this could make your pc crash, if you don't trust the application then I reccommend allowing this. Would you like to allow this application to open startup.str for writing? " or something like that, and then of course having a way to disable warnings

I can see that warning becoming extermely annoying on a home PC ... and finally disabled when a malware comes into the play

now about ring3 drivers:
I want to support ring3 drivers, supporting things like interrupt installing and port access, but also it would prevent some things such as a gpf crashing your pc(also it would enable me to control what ports can be accessed...)

Main difficulty with RING3 driver is PCI DMA ... every device can potentially write to any memory location, if instructed so. and every device has its own way to receive its instructions, so you cannot prevent a ring-3 driver to ask your UDMA disk or your network card to screw page tables etc.

That would eliminate the vast majority of the utilities I use for various things that are simple download-extract-use affairs

imho, you should have the option to run every program in its own "environment" where it cannot do any harm. that is, all it has is a /tmp filesystem and some-of-its-own preference/setting, but it cannot access anything else.
Yet, you can "export" data to a program by OS-controlled means such as shell operations or file dialog boxes.

That would eliminate the vast majority of the utilities I use for various things that are simple download-extract-use affairs

• Download package to /my/home/some.pak
• Extract package to /my/home/some.app
• Run the application to automatically install it to a system-default or app-specific folder.
  A virus scanner might also request a scan of the file.
• Run the application again to use it.

It's just one more step. A small price to pay for [potentially] a lot of added security.

I want to support ring3 drivers, supporting things like interrupt installing and port access

I've heard it's certainly doable. For interupts (depending on how your IPC, etc works) you could abstract them as a message sent to a process, or perhaps could cause the unblocking of a thread (there is no need for the driver to IRET or EOI - the stub can do that fine before the driver actually gets to handle what the interrupt was about). Both of these would also allow for interrupt sharing, which is good! I'm afraid I'm not sure enough to be acurate as to how to implement port access.

For access to system files, etc I had an interesting idea - a capabilities like system, whereby each program is given keys by the user, and when a program wants to say, open a file, the OS checks to see if the program has the key that is required to do so. Now, a simple extension of that could allow a flag to be included that would mean to perform an action, even with the key, the user would be consulted as to whether the program should be allowed to do this. If this was implemented properly (ie made psycologically acceptable by default rulesets, etc), it could effecively stifle viruses, by means of preventing typical virus behaviour (ie modifying code, accessing files of a type the program should normally use, etc). The main advantage of this is you would no longer have to waste CPU time running virus checkers and their update processes.

Thoughts?

This whole thing sounds like Windows Vista a little too much to me. Have you ever used it? If yes, you already that how annoying it is to get asked if you want to do x or y for z application....

Hi,

OScoder wrote:

I want to support ring3 drivers, supporting things like interrupt installing and port access

I've heard it's certainly doable. For interupts (depending on how your IPC, etc works) you could abstract them as a message sent to a process, or perhaps could cause the unblocking of a thread (there is no need for the driver to IRET or EOI - the stub can do that fine before the driver actually gets to handle what the interrupt was about). Both of these would also allow for interrupt sharing, which is good! I'm afraid I'm not sure enough to be acurate as to how to implement port access.

For IRQs you'd either deliver the IRQ via. IPC (e.g. messages), or use some form of callbacks where the IRQ handler switches tasks/address spaces, calls the callback and then switches back. Using IPC is easier for both the OS and the the device driver (no special "doing an IRQ" scheduler mode, and no re-entrancy problems within each IRQ handler), but callbacks would probably be a little better for IRQ latency.

For I/O port protection there's 3 methods. The first method is to use the I/O permission bitmap in the TSS. With this method I/O port instructions happen fast because all the protection checks are done by hardware, but if you're using software task switching you need to update the I/O permission bitmap during task switches. In addition this method doesn't let you protect parts of an I/O port - for example, if an I/O port is shared by seperate things (e.g. system reset, gate A20 and keyboard controller; CMOS and NMI enable/disable, etc) then you have to give the device driver access to the entire I/O port and can't give it access to some bits in an I/O port while protecting other bits.

The next method is to have kernel API functions, where the device driver calls the kernel API function instead of using I/O port instructions. The kernel functions check if access should be permitted and does the I/O port access at CPL=0 before returning to CPL=3.

The last method is to emulate I/O port instructions in the general protection fault exception handler. This can be a little messy (depending on how much other stuff the GPF handler does) and is probably the slowest way due to the overhead within the GPF handler (in addition to the CPL=3 -> CPL=0 -> CPL=3 context switches). It's also the most flexible way - you can protect certain bits of specific I/O ports, and if you trust a device driver you could set IOPL=3 to disable I/O port protection (and all the overhead). For example, you could run a device driver in "secure" mode, and then switch over to "fast" mode once you're convinced it's not going to attempt any wrong I/O port accesses, just by changing 2 bits in it's EFLAGS.

Of course you can combine these I/O port protection methods in a variety of ways.

There's also some other things that the OS needs to protect and/or allow device drivers to share access - ISA DMA controllers, PICs/APICs, memory mapped I/O ranges and MTRRs, and AGP/PCI configuration space.


Cheers,

Brendan

OScoder said capabilities. I was just going to reply same. It is a neat concept about a system where people have authorities to do something, and they give them to processes(which haven't authorities) allowing them to do different things.

Popups are damn annoying, I wish nobody ever had invented those. Same thing with windows! They always overlaps and I can't find my programs then.

The capability based system sounds great to me; I have an idea how this could be designed (from the UI point of view).

Basically, the operating system shell would be given the capability to access every file the user can access. Now, when an app needs access to a file, it makes a request to the shell process for a capability. The shell would then popup an 'Open' dialog, and will then give a capability (to access whichever file the user chose) to the app.

This works in the same way as existing systems, it's transparent to the user, yet it's so much more secure

Cheers,
The Senaus

For access to system files, etc I had an interesting idea - a capabilities like system, whereby each program is given keys by the user, and when a program wants to say, open a file, the OS checks to see if the program has the key that is required to do so. Now, a simple extension of that could allow a flag to be included that would mean to perform an action, even with the key, the user would be consulted as to whether the program should be allowed to do this. If this was implemented properly (ie made psycologically acceptable by default rulesets, etc), it could effecively stifle viruses, by means of preventing typical virus behaviour (ie modifying code, accessing files of a type the dprogram should normally use, etc). The main advantage of this is you would no longer have to waste CPU time running virus checkers and their update processes.

I about think that is what I want to do...
and also to keep a virus from modifying an application with a key I will use checksums!
yea I'm not far enough along to even begin implementing this but anyway

The last method is to emulate I/O port instructions in the general protection fault exception handler. This can be a little messy (depending on how much other stuff the GPF handler does) and is probably the slowest way due to the overhead within the GPF handler (in addition to the CPL=3 -> CPL=0 -> CPL=3 context switches). It's also the most flexible way - you can protect certain bits of specific I/O ports, and if you trust a device driver you could set IOPL=3 to disable I/O port protection (and all the overhead). For example, you could run a device driver in "secure" mode, and then switch over to "fast" mode once you're convinced it's not going to attempt any wrong I/O port accesses, just by changing 2 bits in it's EFLAGS.

That I never thought about, but it is a very neat way to handle it. I like that a lot, Brendan.