linux-kernel - Re: [RFC] status of execve() work - per-architecture patches solicited

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, 11 Sep 2012 13:39:54 +1000
From:	Greg Ungerer <gregungerer@...tnet.com.au>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] status of execve() work - per-architecture patches solicited

On 09/11/2012 02:49 AM, Al Viro wrote:
> On Mon, Sep 10, 2012 at 11:40:11PM +1000, Greg Ungerer wrote:
>> Hi Al,
>>
>> On 09/08/2012 04:20 AM, Al Viro wrote:
>>> 	To architecture maintainers: please, review the current
>>> situation in git.kernel.org/pub/scm/linux/kernel/git/viro/signal #execve2
>>> and consider sending the corresponding patches for missing architectures.
>>
>> I can see you have some m68k patches in there as well.
>> They tested good on standard m68k (under emulator) and good on non-mmu
>> ColdFire. But it is geting an exception when I run on ColdFire with MMU
>> enabled:
>>
>> ...
>> Creating 1 MTD partitions on "RAM":
>> 0x000000000000-0x0000001b8000 : "ROMfs"
>> TCP: cubic registered
>> NET: Registered protocol family 17
>> VFS: Mounted root (romfs filesystem) readonly on device 31:0.
>> *** FORMAT ERROR ***   FORMAT=4
>> Current process id is 1
>> BAD KERNEL TRAP: 00000000
>> Modules linked in:
>> PC: [<0002562a>] 0x02562a
>> SR: 2704  SP: 0383dfc4  a2: 00000000
>> d0: 00000000    d1: 00000000    d2: 00000000    d3: 00000000
>> d4: 00000000    d5: 00000000    a0: 00000000    a1: 00000000
>> Process init (pid: 1, task=0383a000)
>> Frame format=4 eff addr=00000000 pc=6000169a
>> Stack from 0383e000:
>> Call Trace:
>> Code: 6610 4cd7 073e 4fef 0020 201f 588f dfdf <4e73> 2228 0004 46fc
>> 2000 0801 0007 66ff ffff c2ea 598f 4fef ffe8 48d7 78c0 486f
>> Disabling lock debugging due to kernel taint
>>
>> It is trapping at the return from exception (rte) in Lreturn.
>> Looks like it doesn't like the "format" field of the new stack frame
>> for some reason. If I get a few minutes tomorrow I'll dig into it.
>
> Interesting...  What it should get is format 0, same as before the change.

Thats a problem on ColdFire. The format field of the stack frame would
normally be 0x4 for a long-word aligned user stack pointer. The current
start_thread code doesn't set this on the ColdFire/MMU case, though we
do for the non-mmu case. The old code inherited this from the stack
frame of exec calling process.

So I will rework the m68k start_thread() code so it sets it explicitly
for all ColdFire cases.

With this fixed up the new exec code works in all cases I have tested
with ColdFire/MMU then.


> BTW, is there any convenient way to get an emulated coldfire-MMU system?

I only test it on real hardware. But it looks like qemu has coldfire
emulation. I haven't tried it, but as of version 1.0 it listed supported
ColdFire CPU's as:

     m5206
     m5208
     cfv4e

The cfv4e core is capable of having an MMU, so maybe someone is working
on it. I must go and check 1.2.0, it might be better.


> For m68k I'm using aranym with sid/m68k from debian-ports.org and it seems
> to work fine these days, but that obviously won't do for coldfire - neither
> the emulator itself, nor the userland (AFAICS, gcc will happily generate
> instructions that use weird addressing modes unless told not to, so I would
> be extremely surprised if normal debian m68k binaries would run on coldfire,
> MMU or no MMU).

Yeah, no way it will work without the appropriate compiler switches on
when generating even userland binaries.

Regards
Greg


> BTW, the same question goes for many other embedded targets - I'm using
> qemu for arm and mips and hercules for s390; alpha, parisc, ppc32 and sparc64 -
> on actual hardware, amd64 and i386 - on kvm guests (all with debian userland);
> ia64 kinda-sorta works with ski, but it's very much imperfect...  I think
> sh (at least sh4) should be usable with qemu as well, but I hadn't set that
> up yet.  sparc32 is usable on qemu, but only with very old userland.
> Everything else...  In theory, quite a few ought to be usable if one
> bootstraps uclinux userland with qemu, but I've no idea how well does that
> work in practice.  And seeing that e.g. FRV eval boards go for several
> hundred dollars even on ebay, let alone from manufacturer, I'd rather not
> add the actual hardware to the pile here ;-/
>
> What do people actually use?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

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