All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@colorfullife.com>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Cc: Dave Jones <davej@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: EFAULT reading /dev/mem... - broken x86info
Date: Mon, 10 Nov 2003 19:59:11 +0100	[thread overview]
Message-ID: <3FAFDFFF.70100@colorfullife.com> (raw)
In-Reply-To: <20031110180551.GA20168@vana.vc.cvut.cz>

Petr Vandrovec wrote:

>On Mon, Nov 10, 2003 at 06:17:37PM +0100, Manfred Spraul wrote:
>  
>
>>DEBUG_PAGEALLOC unmaps pages on kmem_cache_free and __free_pages(). The 
>>pages are mapped again during get_free_pages and kmem_cache_alloc.
>>
>>0x86000 looks like a normal page - what guarantees that it's not used by 
>>the kernel?
>>    
>>
>
>With DEBUG_PAGEALLOC there is no problem with page if it is USED by the kernel.
>Problem is if page is NOT USED - in this case kernel does not have it in its
>mapping, and bad thing happen.
>  
>
If the page is used by AGP, then it won't have a mapping either.

>x86info (and other simillar tools for dumping different BIOS structures) just
>scans physical memory for some well known signatures - hoping that kernel did
>not smash these structures.
>  
>
Scanning physical memory is very dangerous: it's undefined what happens 
if a page is mapped multiple times with different cache settings. Athlon 
cpus prefetch whatever they see, and they speculatively set the dirty 
bit in cachelines for WB cacheable pages.

>Up to now it was possible to read whole physical memory from userspace - some 
>pages by reading /dev/mem, some pages by mmaping /dev/mem. Now it is not possible 
>anymore - which I think is bad, as /dev/mem has semantic of it.
>
I think /dev/mem should lie and return 0x00 for pages that are not in 
the linear mapping.

Or /dev/mem users should expect random holes.

--
    Manfred


  reply	other threads:[~2003-11-10 18:59 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-08 16:27 EFAULT reading /dev/mem... - broken x86info Petr Vandrovec
2003-11-10 13:55 ` Richard B. Johnson
2003-11-10 16:11 ` Dave Jones
2003-11-10 16:50   ` Manfred Spraul
2003-11-10 16:56     ` Dave Jones
2003-11-10 17:17       ` Manfred Spraul
2003-11-10 18:05         ` Petr Vandrovec
2003-11-10 18:59           ` Manfred Spraul [this message]
2003-11-10 19:36             ` Mika Penttilä
2003-11-10 19:47               ` Manfred Spraul
2003-11-10 20:24                 ` Dave Jones

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=3FAFDFFF.70100@colorfullife.com \
    --to=manfred@colorfullife.com \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vandrove@vc.cvut.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.