mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Leszek Koltunski <leszek@serwer.3miasto.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Cannot read from /dev/kmem
Date: Wed, 4 May 2005 15:42:45 -0700	[thread overview]
Message-ID: <20050504154245.28d27a6f.rddunlap@osdl.org> (raw)
In-Reply-To: <Pine.NEB.4.60.0505041712240.12334@serwer.3miasto.net>

On Wed, 4 May 2005 17:20:36 +0200 (CEST)
Leszek Koltunski <leszek@serwer.3miasto.net> wrote:

> 
> Kernel 2.6.11 , I cannot seem to be able to read from /dev/kmem... The 
> following little proggie
> 
> #include <stdio.h>
> #include <fcntl.h>
> #include <errno.h>
> 
> struct {
>          unsigned short limit;
>          unsigned int base;
> } __attribute__ ((packed)) idtr;
> 
> struct {
>          unsigned short off1;
>          unsigned short sel;
>          unsigned char none,flags;
>          unsigned short off2;
> } __attribute__ ((packed)) idt;
> 
> int main()
> {
>          int result, kmem = open ("/dev/kmem",O_RDONLY);
> 
>          asm ("sidt %0" : "=m" (idtr));
>          printf("idtr base at 0x%X\n",(int)idtr.base);
> 
>          if (kmem<0) return 1;
> 
>          if (lseek(kmem,  idtr.base + 8*0x80,SEEK_SET) != idtr.base + 
> 8*0x80 )
>          {
>                  perror("kmem lseek"); exit(1);
>          }
> 
>          result = read(kmem, &idt , sizeof(idt) );
> 
>          if( result != sizeof(idt) )
>          {
>                  printf("result: %d, sizeof(idt)= %d errno=%d\n", result, 
> sizeof(idt), errno);
>          }
> 
>          close(kmem);
> 
>          return 0;
> }
> 
> returns
> 
> utumno:/home/leszek/progs/module/hijack# ./test
> idtr base at 0xC0423000
> result: -1, sizeof(idt)= 8 errno=22
> 
> ??? EINVAL
> 
> I remember this working on a 2.4.x kernel....

Hm, let me see if I can explain what I see here...

vfs_llseek() sets f_pos (file position) to 0xffffffff.c04230000 (due
to sign extension).  In read(), rw_verify_area() sees that pos
as < 0 and balks on it.

I futzed around with lseek() and read(), to no avail.
However, I did get your test program to work by using lseek64()
instead of lseek().  It prints (after I added code) a selector
value of 0x60, which makes sense.

Maybe you have to use llseek() or lseek64() with large 32-bit
file offsets (that look like 32-bit negative numbers)...
I dunno.

HTH.
---
~Randy

      parent reply	other threads:[~2005-05-04 22:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-04 15:20 Leszek Koltunski
2005-05-04 16:29 ` Arjan van de Ven
2005-05-04 22:42 ` Randy.Dunlap [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050504154245.28d27a6f.rddunlap@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=leszek@serwer.3miasto.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®