outb() problem - Segmentation fault

[Cerf]

Yo yo yo,

This might cross into one of my other threads, mabie not, but anyway...

What I want to do is read the state of pin one on /dev/lp0


#include <stdio.h>
#include <unistd.h>
#include <asm/io.h>

int main()
{
/* Read from the status port (lp0 + 1) and display the result */
printf("status: %d\n", inb('/dev/lp0' + 1));

return 0;
}


Now everything is compiling but, when I run the program I get a


[Cerf@localhost parallelport]$ ./parallelport
Segmentation fault


Does anyone know whats going on?

[bwkaz]

You need permission to be able to directly access I/O ports in Linux; if you didn't need that permission, you could easily undermine the security of the OS. Use ioperm() to get that permission (if you know much about the x86 task segment, you should know that there are I/O permission bits in that segment, to specify which ports the task has permission to access; the ioperm() call modifies those bits in your task segment).

There is also the iopl() call, to modify the system-wide privilege level required to do I/O, but this is NOT recommended, as it allows your program (or anything that your program executes, e.g. as a result of a buffer overflow) to completely disable interrupts, for example, which will bring the system to a screeching halt pretty quickly.

You will also need to be root to be able to call either ioperm() or iopl().

Or, you could just look through the kernel source to see if there are any ioctl()s that you can do on /dev/lp* to find out the contents of the status register, as that would depend on code already in the kernel that runs at a higher privilege level anyway.

[Cerf]

I'm new to the linux programming, can you give me an example using ioperm().

The man page is only giving me a

int ioperm(unsigned long from, unsigned long num[/], int [u]turn_on);


and I dont know what it means by from, num, or turn_on

[bwkaz]

The manpage explains what it means by from, num, and turn_on about three lines down from the line you posted.

[Strogian]

Permissions are not inherited on fork, but on exec they
are. This is useful for giving port access permissions to
non-privileged tasks.


(quoted from the ioperm() manpage)

That makes it seem like there should be a program to set permissions for you, so you don't need an ioperm() call in the program. Is there anything like that?

[sploo22]

No, that would be an extreme security risk. Any program that gets direct hardware access could literally destroy your hardware. Make SURE you know what you're doing before you mess with this stuff.

And by the way, you can't pass a string to inb/outb/etc. You need to give them a port number from 0-65535.

[Strogian]

I mean something like this:

ioperm 0x742,3,1 "./myprog"

Like an 'su' for ioperms, I guess.

I never saw where the security risk was, anyway. You have to be root in order to do this, right? If you're root, then there _is_ no security, no matter how much crap you have to go through, no matter how many system calls you have to run before you can access something. ;)

Only thing would be if the ioperm were set with a secure program, and then the effective user/group was changed to run (exec) a possibly insecure program. Then the insecure program only has the permissions you want it to have.

[sploo22]

Oh, OK. I misunderstood what you were saying. But it doesn't really make sense to make it a separate program. If the program needs to do direct I/O, it might as well call ioperm() itself.

[bwkaz]

There is no such program (at least not in any standard Linux utility set that I know of), because it takes a lot less system time to call ioperm() than it takes to call exec().

[Cerf]

I am posting this apology because of my un-provoked ranting on this fourm. I want to especially apologize to everyone who tried to help me when I was too emotional to read what was right infrount of me (I was also able to find a windows solution @ http://www.logix4u.cjb.net/ that I am going to try to port to linux in a few weeks time).

SORRY

Thanks for all the help too


cc - Programming with the parallel port (http://www.justlinux.com/forum/showthread.php?s=&threadid=127676)