linux-kernel - Re: accessing file operations directly in the kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2c918050811070646y1bb5771bo70aff584252d7d1@mail.gmail.com>
Date:	Fri, 7 Nov 2008 14:46:51 +0000
From:	andy <rootstrap@...glemail.com>
To:	"Robert Hancock" <hancockr@...w.ca>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: accessing file operations directly in the kernel

I agree with you! But there are cases where standards
are followed from certain developers. I have to deal with a
very "peculiar" arrangement of a set of requirements to access
a serial device driver. The type of code below gives me what I need, I think.

filp = filp_open("/dev/device1", O_WRONLY, 0);

if (filp->f_op->ioctl(filp->f_dentry->d_inode, filp,
							CMD,
							(unsigned long) &args) != 0) {
        		goto failed;
}

Regards
Andy

On 11/7/08, Robert Hancock <hancockr@...w.ca> wrote:
> andy wrote:
>
> > Hi,
> >
> > I am dealing with an interesting situation, which I have to access a
> > serial device driver
> > from the kernel space. I tried to use sys_open, sys_ioctl ... but
> > there is a problem
> > with the file descriptors.  Now, I started using direct calls to the
> > drivers functions
> > driver_open, driver_ioctl... passing the *inode from user_path_walk(),
> > but it doesn't
> > seem that works right. This serial device is going to be used only
> > from the other
> > module that runs in the kernel.
> >
>
>  For some reason this kind of question (using file operations inside the
> kernel) gets asked a lot. The short answer is that if you're asking it, you
> likely have a wrong design. It's just not the right thing to do. For one
> thing, file descriptors belong to a process, so just stealing the FD space
> from some random process is unlikely to do the right thing.
>
>  If you really need to do this, adding hooks to the serial device driver
> would seem a more logical thing to do.. but even that seems a suspicious
> design. It would be best if you explained what it is you're actually trying
> to accomplish.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/