Re: [RFC] invalidate_mmap_range() misses remap_file_pages()-affected targets

From: William Lee Irwin III (wli_at_holomorphy.com)
Date: 10/12/03

  • Next message: Jan Schubert: "Q: Cryptoloop missing in kernel-2.4"
    Date:	Sun, 12 Oct 2003 12:38:41 -0700
    To: Andrew Morton <akpm@osdl.org>
    
    

    On Sun, Oct 12, 2003 at 04:53:32AM -0700, Andrew Morton wrote:
    > I was going to just not bother about this wart. After all, we get to write
    > the standard on remap_file_pages(), and we can say "the
    > truncate-causes-SIGBUS thing doesn't work". After all, it is not very
    > useful.
    > But I wonder if this effect could be used maliciously. Say, user A has
    > read-only access to user B's file, and uses that access to set up a
    > nonlinear mapping thereby causing user B's truncate to not behave
    > correctly. But this example is OK, isn't it? User A will just receive an
    > anonymous page for his troubles.
    > Can you think of any stability or security scenario which says that we
    > _should_ implement the conventional truncate behaviour?

    At some point we burned a bit of effort to ensure we wiped all the ptes
    and all the faulting looped until we finished when we vmtruncate();
    not handling is a loophole in that, and if anything assumes it won't
    find vmtruncate()'s orphans in-kernel, it will break. Apart from that
    it's not so large an issue. I'm not so much attached to coddling
    userspace (remap_file_pages() users should not be naive) as to shoring
    up invalidate_mmap_range() with its intent (unmapping file offset ranges
    instead of virtualspace ranges). Someone else might scream later.

    Also, tlb_remove_tlb_entry()'s ordering with ptep_get_and_clear() seems
    to be handled on ppc* by not having ptep_get_and_clear() fully clear the
    pte, which is disturbing, but a sign ppc* maintainers already handle it.

    -- wli
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Jan Schubert: "Q: Cryptoloop missing in kernel-2.4"

    Relevant Pages

    • Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
      ... this case is useless on ppc... ... completely instead and define it's arch impl. ... ptep_set_dirty_accessedresponsibility to do the TLB flush if ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Posssible bug in kernel/irq/handle.c
      ... > enable interrupts behind our back, and expects us to call a firmware ... handling to work so that it's usabel for PPC. ... Be vewy vewy caweful when changing that code, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: PowerMac 8500 (summary)
      ... [To reduce noise, i've replied personally to specific points not ... Yeah, much of what was in the earlier summary has been cleared up. ... One not specific to PPC is that it would be better if 'bootlogd' ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: swsusp_restore crap
      ... On Út 15-03-05 14:31:56, Benjamin Herrenschmidt wrote: ... > generic swsusp code and moves it to arch/i386. ... > ppc with swsusp enabled. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: rc5 seemed to kill a disk that rc4-mm1 likes. Also some X trouble.
      ... > works when root runs the X server and causes problems for normal users ... X uses /dev/mem, it doesn't use sysfs nor proc on x86, though it does ... use proc for config space access on ppc. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)