linux-kernel - Re: [PATCHv4 3/3] edac: altera: Add EDAC support for Altera SoC SDRAM Controller

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

Message-ID: <CAF03EBc05N3f5p0TPieLZx=mwQkU5Fr4Vq7DwMpUjdiSvs3pwA@mail.gmail.com>
Date:	Wed, 14 May 2014 08:38:21 -0500
From:	Thor Thayer <tthayer.linux@...il.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Thor Thayer <tthayer@...era.com>,
	Rob Herring <robherring2@...il.com>, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	Kumar Gala <galak@...eaurora.org>,
	Rob Landley <rob@...dley.net>, linux@....linux.org.uk,
	Dinh Nguyen <dinguyen@...era.com>, dougthompson@...ssion.com,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-edac@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv4 3/3] edac: altera: Add EDAC support for Altera SoC SDRAM Controller

On Mon, May 12, 2014 at 7:12 PM, Borislav Petkov <bp@...en8.de> wrote:
> On Mon, May 12, 2014 at 06:36:57PM -0500, tthayer@...era.com wrote:
>> +     ptemp[0] = 0x5A5A5A5A;
>> +     ptemp[1] = 0xA5A5A5A5;
>> +     /* Clear the error injection bits */
>> +     regmap_write(drvdata->mc_vbase, CTLCFG, read_reg);
>> +     /* Ensure it has been written out */
>> +     wmb();
>> +
>> +     /*
>> +      * To trigger the error, we need to read the data back
>> +      * (the data was written with errors above)
>> +      * The ACCESS_ONCE macros are used to prevent the
>> +      * compiler optimizing these reads out.
>> +      */
>> +     reg = ACCESS_ONCE(ptemp[0]);
>> +     read_reg = ACCESS_ONCE(ptemp[1]);
>> +     /* Force Read */
>> +     rmb();
>
> Right, I still am a bit unsure about this thing. So sure, we funnel
> ptemp through an asm() block which stops the optimizer but we assign the
> results to reg and read_reg, i.e. two local variables which aren't used
> in this function anymore.
>
> Thus, I don't see what stops the compiler from discarding them along
> with the ACCESS_ONCE() reads at some point, when it becomes really
> smart. Basically killing
>
>> +     reg = ACCESS_ONCE(ptemp[0]);
>> +     read_reg = ACCESS_ONCE(ptemp[1]);
>
> as they have to effect.
>
> Maybe we can do the reads in asm - this should be pretty safe.
>
> I.e., something like this:
>
>       asm volatile("" : "=r" (reg), "=r" (read_reg),
>                       : "0" (ptemp[0]), "1" (ptemp[1]));
>
> and it does it on x86 (did a small test program) by shuffling the values
> through registers so we definitely have the reads.
>
>         .loc 1 28 0
>         movl    -48(%rbp), %edx # ptemp, D.2240
>         movl    -44(%rbp), %eax # ptemp, D.2240
>         .loc 1 27 0
>         movl    %edx, -28(%rbp) # reg, reg
>         movl    %eax, -32(%rbp) # read_reg, read_reg
>
> Btw, if you only want to do the reads, you can simply tell gcc to put them in
> registers
>
>       asm volatile("" :: "r" (ptemp[0]), "r" (ptemp[1]));
>
> and be done with it but I don't know how smart it is with register
> allocation so as to recognize that they're already in registers (when
> they already are in some registers) and discard the reads.
>
> Fun stuff! :-)
>
> --
> Regards/Gruss,
>     Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --

Hi Boris.

I'll look into that. I think I will use the registers in a
edac_printk(). Since this is a debugging trigger function, the
printout may be useful anyway.

Thanks!
--
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/