On Mon, Mar 4, 2019 at 9:46 PM David Brown wrote:
>
> On 19/02/2019 11:23, P J P wrote:
> > Hello,
> >-> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
> >
> > This RFE is about providing gcc option(s) to eliminate information leakage
> > issues from programs. Information leakage via unini
On 06/03/2019 02:50, Segher Boessenkool wrote:
> On Tue, Mar 05, 2019 at 09:36:56PM +0100, David Brown wrote:
>> On 05/03/2019 19:37, Segher Boessenkool wrote:
>>> On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
void foo(void) {
char key[20];
strcpy(key, "Top sec
On Tue, Mar 05, 2019 at 09:36:56PM +0100, David Brown wrote:
> On 05/03/2019 19:37, Segher Boessenkool wrote:
> >On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
> >>void foo(void) {
> >> char key[20];
> >> strcpy(key, "Top secret");
> >> usekey(key);
> >> memset(key, 0,
On Tue, Mar 05, 2019 at 02:17:51PM -0700, Martin Sebor wrote:
> The SECURE project adds the function attribute stack_erase that
> serves the purpose described above. It works on stack frames by
> design rather than applying to individual stack objects.
> The presentation they delivered at Cauldron
On 3/5/19 1:36 PM, David Brown wrote:
On 05/03/2019 19:37, Segher Boessenkool wrote:
Hi!
On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
Forcing "stolen_key" to be zero initialised does not help anyone -
options for that just make code slower and hide errors that would occur
wit
On 05/03/2019 19:37, Segher Boessenkool wrote:
Hi!
On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
Forcing "stolen_key" to be zero initialised does not help anyone -
options for that just make code slower and hide errors that would occur
with other compiler options. The challen
Hi!
On Mon, Mar 04, 2019 at 09:45:37PM +0100, David Brown wrote:
> Forcing "stolen_key" to be zero initialised does not help anyone -
> options for that just make code slower and hide errors that would occur
> with other compiler options. The challenge is to make sure /key/ is
> zeroed out aft
On 19/02/2019 11:23, P J P wrote:
Hello,
-> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
This RFE is about providing gcc option(s) to eliminate information leakage
issues from programs. Information leakage via uninitialised memory has beena
chronic/recurring issue across all software.
On Mon, Mar 4, 2019 at 11:44 AM P J P wrote:
>
> On Tuesday, 19 February, 2019, 3:55:35 PM IST, P J P
> wrote:
> >
> >Hello,
> >
> > -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
> >
> >This RFE is about providing gcc option(s) to eliminate information leakage
> >issues from programs. I
On Tuesday, 19 February, 2019, 3:55:35 PM IST, P J P
wrote:
>
>Hello,
>
> -> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
>
>This RFE is about providing gcc option(s) to eliminate information leakage
>issues from programs. Information leakage via uninitialised memory has been
>a chronic/re
Hello,
-> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
This RFE is about providing gcc option(s) to eliminate information leakage
issues from programs. Information leakage via uninitialised memory has beena
chronic/recurring issue across all software. They are found quite often andmay
le
11 matches
Mail list logo
