linux-kernel - Re: [PATCH 3/3] [BFIN] Blackfin documents and MAINTAINER patch

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

Message-Id: <6.1.1.1.0.20060925011906.01ecea00@ptg1.spd.analog.com>
Date:	Mon, 25 Sep 2006 01:51:34 -0400
From:	Robin Getz <rgetz@...ckfin.uclinux.org>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Greg KH <gregkh@...e.de>, luke Yang <luke.adi@...il.com>
Subject: Re: [PATCH 3/3] [BFIN] Blackfin documents and MAINTAINER patch

Paul indicated:
> > +cache-lock.txt
> > +     - HOWTO for blackfin cache locking.
> > +
>
>This is a generic enough of a feature that I suspect we should hash out a 
>common API for it rather than having people roll their own.

That sounds like a good idea. From the few people that use this, I think a 
much simpler interface would be desirable.

For data, it is easy - something similar to the processor specific 
xx_flush_range(start,end) - have a xxx_lock_range(start,end) would be good, 
and easy to implement.

The only thing I am not sure of - is how to force things into cache. For 
data - it is easy - do a read, and then lock it. For instruction - for 
those architectures which have separate instruction cache (like Blackfin) 
it is much harder. The only way to get code into cache is to execute it. 
(ergo the existing interface).

Normally - what we do when locking things in cache is specific to the hardware.
   - to prevent isr polluting cache, we disable interrupts
   - If the code to be locked has a possibility of already being in the 
instruction cache, we invalidate the entire cache first
   - we locks 3/4 of the cache - forcing any code to be put into a specific 
location.
   - execute the code of interest (once)
   - unlock the 3/4 of cache, and lock the 1/4 where the code of interest 
is located.
   - turn back on interrupts.

Because the algorithm is so specific to the hardware - I am not sure how to 
make instruction as generic as data could be.

How does SH cache handle things like this?

-Robin
-
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/