public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Michael Brown <mebrown@michaels-house.net>
Cc: Andi Kleen <ak@muc.de>,
	linux-kernel@vger.kernel.org, marcelo.tosatti@cyclades.com
Subject: Re: [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED
Date: 1 May 2004 17:01:36 +0200
Date: Sat, 1 May 2004 17:01:36 +0200	[thread overview]
Message-ID: <20040501150136.GA23636@colin2.muc.de> (raw)
In-Reply-To: <1083382204.1203.2971.camel@debian>

> -- This information is, in the very near future, _not_ going to be
> static anymore. There will be systems that update the information in
> dynamically during SMIs.

That's fine - /dev/mem can handle that too. An user will have to
poll for changes anyways, so having it it /proc does not have
any advantages.

I would see the sense if there was an interrupt to notify the
the system of changes, but there isn't ;-)

> 
> -- SMBIOS consists of two things, the table entry point and the table
> itself. The table entry point is always in 0xF0000 - 0xFFFFF.
> Traditionally, the actual table has been here as well. BIOS is running
> out of space here and future systems are moving this information to high
> memory. /dev/mem will not allow access to memory above top of system
> RAM.

mmap /dev/mem of high memory should work. Did you try it?
For read/write it would be fairly easy to add, just needs a kmap.

> -- Red Hat has a /dev/mem patch in their tree that restricts access to
> RAM above 1MB. 

That's their breakage.

Clearly it is a useless change anyways because you can easily circumvent
it by just accessing any bus master hardware in the system.

> This procfs/sysfs driver allows access to smbios information by
> non-root, non CAP_SYS_RAWIO users. I've had several occasions where I
> have been bitten by having to be root to read smbios when I did not need
> root for anything else.

That is what suid root was invented for. It is a fairly nifty mechanism,
did you ever try it?  I know that some sysadmins try to get away from
it, but that is clearly misguided because it is not any more dangerous than
adding more kernel code.

-Andi

  parent reply	other threads:[~2004-05-01 15:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1QvX0-A4-29@gated-at.bofh.it>
2004-04-30 19:22 ` [PATCH 2.4] add SMBIOS information to /proc/smbios -- UPDATED Andi Kleen
2004-05-01  3:30   ` Michael Brown
2004-05-01  3:43     ` Michael Brown
2004-05-01 15:01     ` Andi Kleen [this message]
2004-05-03 23:49 Michael_E_Brown
  -- strict thread matches above, loose matches on Subject: below --
2004-05-01 21:00 Lev Makhlis
2004-05-01 21:20 ` Andi Kleen
2004-04-30  2:21 Michael Brown
2004-04-30  3:34 ` viro
2004-04-30  4:37   ` Michael Brown
2004-05-03 23:40 ` Marcelo Tosatti

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=20040501150136.GA23636@colin2.muc.de \
    --to=ak@muc.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=mebrown@michaels-house.net \
    /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