linux-kernel - Re: kernel BUG at kernel/kallsyms.c:222!

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:	Tue, 12 Nov 2013 17:36:06 +0000
From:	Jonathan Austin <Jonathan.Austin@....com>
To:	Ming Lei <tom.leiming@...il.com>
CC:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Michal Marek <mmarek@...e.cz>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>, Axel Lin <axel.lin@...ics.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: kernel BUG at kernel/kallsyms.c:222!

On 12/11/13 03:22, Ming Lei wrote:
> On Tue, Nov 12, 2013 at 3:32 AM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
>> On Mon, Nov 11, 2013 at 05:15:29PM +0000, Jonathan Austin wrote:
>>> I've tested the patch below and it solves the ARM side of things - so
>>> gives you an option other than a complete revert. Happy to put this in to
>>> RMK's patch system if you'd prefer not to have to revert and he's happy
>>> with the patch.
>>
>> I think this is the right solution because it then means that this symbol
>> has the same meaning whether on MMU or !MMU - and getting rid of these
>> kinds of gratuitous variances are the only way that !MMU is going to
>> become less fragile.
>
> The patch only fixes problem on arm, and other !MMU&&!ARM archs
> should be affected too.
>
> Also there is no CONFIG_PAGE_OFFSET defined for some ARCHs,
> such as 64bit ARCHs.
>
> Currently, I suggest to filter only on ARM as attachment patch if we plan
> to merge Jonathan's patch, otherwise a more complicated approach has
> to be figured out  to do the filter(such as, define a readonly symbol in
> kernel to store PAGE_OFFSET, and let scripts/kallsyms use it for
> filtering).

I'm happy with that approach, though allowing only ARM seems a bit
conservative - is it the only architecture we actually expect to work?

Jonny
>
>
>
> Thanks,
>


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

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