linux-kernel - Re: [PATCH] ARM fix syscall trace return value

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 17 Feb 2009 15:08:16 -0500
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	Viktor Rosendahl <Viktor.Rosendahl@...ia.com>,
	ext Tony Lindgren <tony@...mide.com>,
	"Moiseichuk Leonid (Nokia-D/Helsinki)" <leonid.moiseichuk@...ia.com>,
	"Kallioinen Juha (Nokia-D/Helsinki)" <juha.kallioinen@...ia.com>,
	"Siamashka Siarhei (Nokia-D/Helsinki)" <siarhei.siamashka@...ia.com>,
	"Tamminen Eero (Nokia-D/Helsinki)" <eero.tamminen@...ia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.arm.linux.org.uk" 
	<linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH] ARM fix syscall trace return value

* Russell King (rmk+lkml@....linux.org.uk) wrote:
> On Tue, Feb 17, 2009 at 02:30:15PM -0500, Mathieu Desnoyers wrote:
> > I had the same result as you with the ccnt-based clock I am currently
> > developing, so I went back to a more "solid" and atomic
> > atomic_add_return clock. But I noticed that we still had entry/exit with
> > the same timestamps, so I was really unsure about what was happening,
> > because there is no trace corruption and because I have never, ever,
> > seen that kind of problem on any other architecture (x86, powerpc,
> > mips...). So I fixed the syscall_trace exit parameter,
> 
> Correction: you broke syscall_trace exit by corrupting the syscall number
> stored in the thread_info.
> 

Having a second look, yes, you are right. It's the instrumentation that
has been sent to me which was wrongly expecting scno to contain the
return value. So my patch is incorrect.

> > which now makes sure there is a dependency on the return value.
> 
> I've no idea what dependency you're talking about.  ARM is for the most
> part a very simple architecture and doesn't really have any dependencies.
> The only kind it has are those which are automatically fixed up by the
> hardware (so a load followed by an immediate use causes a pipeline stall.)
> 
> So I really can't figure out what you're going on about.  On top of that
> you're trying to make things do stuff in ways they weren't designed.  Your
> bug report makes zero sense to me.
> 
> > But I want to find out
> > why the atomic add return failed to be atomic in that particular
> > condition. I suspect there is a missing memory barrier in atomic.h.
> 
> In a single CPU context, memory barriers to the same location on ARM
> don't have any effect as far as program accesses are concerned.
> 
> So again we disagree.
> 
> So, how about you tell me exactly what you're doing, give me pointers to
> whatever test is failing, tell me about your hardware that you're testing
> on.
> 
> Until that happens, I'm disinclined to believe any of this reported "bug".
> 

Looking at my trace-clock-32-to-64 code tells me I might have problems
specific to little endian machines. I'll review that.

Thanks for the answer,

Best regards,

Mathieu

> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/