linux-kernel - Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <20061020.125851.115909797.davem@davemloft.net>
Date:	Fri, 20 Oct 2006 12:58:51 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	torvalds@...l.org
Cc:	nickpiggin@...oo.com.au, ralf@...ux-mips.org, akpm@...l.org,
	linux-kernel@...r.kernel.org, anemo@....ocn.ne.jp
Subject: Re: [PATCH 1/3] Fix COW D-cache aliasing on fork

From: Linus Torvalds <torvalds@...l.org>
Date: Fri, 20 Oct 2006 12:54:17 -0700 (PDT)

> Well, sparc always was crud. I can see the missing tlb entry, but if it's 
> been turned read-only, the write-back should still work (it clearly _was_ 
> writable when the write that dirtied the cacheline happened).

I did some more digging, here's what I think the hardware actually
does:

1) On L2 cacheline load, the "user" and "writable" protection
   bits are propagated from the TLB entry into the L2 cache
   line.  Access checks are done on L2 cache hit using this
   cached copy of the two protection bits.

2) On L2 dirty cacheline writeback, the physical address is
   obtained from the TLB

So what you guys are suggesting should probably work fine.
-
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/