linux-kernel - Re: bcm33xx port

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

Date:	Sun, 8 Jun 2008 23:13:22 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Luke -Jr <luke@...hjr.org>
cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-mips@...ux-mips.org
Subject: Re: bcm33xx port

On Sun, 8 Jun 2008, Luke -Jr wrote:

> Is merging with mainline something I can help with, being a beginner in this 
> area generally and not having any part in writing them?

 Well, you can certainly serve as a messenger telling them if they want
people to get proper support from upstream maintainers they better merge
sooner rather than later.  Otherwise it is them who should really be
bothered with cases like yours.

 The general principle is: "merge as soon as you can, even if code is
incomplete" as you get more attention and perhaps developers involved as a
result, some free support (e.g. with bulk changes done automatically to
all the relevant bits in the tree) and avoid duplicated work; also when at
the time of the merge you are told to rewrite your code differently.

> >  Not exactly.  Try harder -- this is simple arithmetic and you've got all
> > the data given above already. :)
> 
> 200 / 2? I'm not really sure what a 'jiffy' is..

 Hmm, I have thought it can be inferred from the code involved or failing
that -- Google...  Well, anyway, a jiffy is a tick of the kernel timer or,
specifically in this context and to be more precise, the interval between
such two consecutive ticks or, in other words, 1/HZ.

> >  I have seen that already and wrote these stores in __bzero are protected.
> > Perhaps the fixup fails for some reason, but you need to investigate it
> > and this is why I suggested to see how the RI handler is reached.  Since
> > this is a known point the failure leads to, you should be able to work
> > backwards from there quite easily.
> 
> Ah, so what you're saying is that perhaps the 'sw' is triggering a TLB 
> exception, and the handler for *that* is causing the RI problem?

 This is almost certain what happens here.  The pointer involved is a
valid (user) address and is correctly aligned, so you cannot get an
address error exception.  A TLB exception is next on the list to check.

 Of course you cannot rule out I-cache corruption or suchlike, but if I
were you, I would start with simple assumptions first.

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