[coreboot] Disabling Auto-Refresh of DRAM Using Coreboot

[Zoran Stojsavljevic]

> For instance, the CPU may convey to the user during boot: “Your DRAM
claims it is made by manufacturer A but
> it is acting like it is made by manufacturer B. Manufacturer B is known
to be susceptible to these hardware trojans, defects, etc.”

Interesting work. To invent SW/FW algorithm to survey DRAM in order to find
out what are retention times, and based upon that to construct SPD flash
info.

The mortal problem with DDRs and refresh times waits just around the
corner, since the technology of the gate, upon shrinking (present gate
sizes around 22/20nm) the refreshing time drops. As the
stochastics/volatility about retention times rises. Very soon it'll hit
Dead End (around 16/14nm).

And... Hitting (with the current technology) The Dead End (complete denial
of Moore's Law, which is imminent), do you think it is worth?

Link to read.
<https://www.techinsights.com/uploadedFiles/Public_Website/Content_-_Primary/Marketing/2013/DRAM_Roadmap/Report/TechInsights-DRAM-ROADMAP-052013-LONG-version.pdf>

Well... It is a true experimental job, and I wish you good luck with it. :-)

Please, keep us posted!

Zoran

On Fri, Mar 24, 2017 at 6:14 PM, Berj K Chilingirian <berjc at mit.edu> wrote:

> Hi Zoran and Peter,
>
> I’m actually interested in the retention time of DRAM cells for
> fingerprinting purposes (i.e. not for any kind of performance tuning). It
> turns out that retention time information (such as the distribution of
> retention times across the cells of DRAM) can be used to identify the
> manufacturer of that DRAM (see here
> <http://www.pdl.cmu.edu/PDL-FTP/NVM/dram-retention_isca13.pdf>,
> especially Figure 8, for details). The paper cited uses an FPGA
> implementation to measure the retention time. In contrast, I’m interested
> in seeing whether this relationship holds under a traditional setup and how
> it may then be leveraged to build secure systems that make their hardware
> (e.g. DRAM) transparent to the user without relying on static information
> like the SPD.
>
> For instance, the CPU may convey to the user during boot: “Your DRAM
> claims it is made by manufacturer A but it is acting like it is made by
> manufacturer B. Manufacturer B is known to be susceptible to these hardware
> trojans, defects, etc.”
>
> This is, of course, a very research oriented project with many strong
> assumptions, but I’m hoping that it will lead to some interesting results
> (it is part of my master’s thesis).
>
> Thus, that is why I need to figure out a way to disable the auto-refresh
> of DRAM ;)
>
> Best,
> Berj
>
> On Mar 24, 2017, at 8:01 AM, Zoran Stojsavljevic <
> zoran.stojsavljevic at gmail.com> wrote:
>
> > Quantify data retention of unpowered memory.
>
> Let us asses/investigate what is the technology of C (capacitor) in the presented
> diagram
> <https://upload.wikimedia.org/wikipedia/commons/b/bd/DRAM_Cell_Structure_%28Model_of_Single_Circuit_Cell%29.PNG> in
> my previous email!
>
> The capacitor in the stacked capacitor scheme is constructed above the
> surface of the substrate. The capacitor is constructed from an *oxide-nitride-oxide
> (ONO) dielectric sandwiched in between two layers of polysilicon plates*
> (the top plate is shared by all DRAM cells in an IC), and its shape can be
> a rectangle, a cylinder, or some other more complex shape. There are two
> basic variations of the stacked capacitor, based on its location relative
> to the bitline—capacitor-over-bitline (COB) and capacitor-under-bitline
> (CUB). In a former variation, the capacitor is underneath the bitline,
> which is usually made of metal, and the bitline has a polysilicon contact
> that extends downwards to connect it to the access transistor's source
> terminal.
>
> Well, let us search more (on the ONO - Oxide-Nitride-Oxide dielectric
> material):
>
>  *The commonly used technology for non-volatile Flash memory application
> consists of a stacked-gate transistor with dual gates. The
> Oxide-Nitride-Oxide (ONO) stacks constitute the inter-poly dielectric layer
> between those gates.* These top and bottom polycrystalline silicon plates
> are also known as the control gate (CG) and the floating gate (FG)
> respectively. During read and write operation of a flash memory device, a
> high electrical bias needs to be applied through the control gate in order
> for electrons to be tunneled through the thin tunnel oxide towards the
> floating gate which is surrounded by dielectric material.
>
> Although the same material is used in DRAMs and FLASHes (as in one case
> for dielectric in Cs, in other channel material for the FETs with dual
> gates), the design of DRAMs and FLASHes are essentially very different, as
> I see. It seems to me that in case of C, ONO is dielectric which holds the
> capacitor charge, and leaks it through dielectric, in the case of dual gate
> FETs we have here The Tunnel Effect, which captures some number of free
> electrons inside the ONO.
>
> Well... I am also curious (as you, Peter), what will be the retention
> time, but, as a difference to you, I think that after maximum of 7.8us x 2
> some bits (maybe 5% of them, even less, but certainly more than 0.1%) will
> be corrupted.
>
> Now, after the quick analysis/assessment I made, now I understand why all
> the DRAM companies are trying to pack future DDRs as FLASHes. Never came to
> me before to investigate this... But there is always the first time
> (courtesy of Mr, Chilingirian, Massachusetts Institute of Technology). ;-)
>
> Zoran
> _______
>
> On Fri, Mar 24, 2017 at 12:19 PM, Peter Stuge <peter at stuge.se> wrote:
>
>> Zoran Stojsavljevic wrote:
>> > I am not sure what are you really trying to do,
>>
>> Quantify data retention of unpowered memory.
>>
>>
>> > and, mostly WHY you are trying to do what you are trying to do?!
>>
>> To challenge the assumption that data is lost without power.
>>
>> It is an interesting area of research because that assumption - or
>> simplification - is so widespread, although not at all correct.
>>
>>
>> //Peter
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170325/e0c8d76c/attachment-0001.html>