Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Jun 2015 13:08:05 +0900
From: Yoshinori Sato <ysato@...rs.sourceforge.jp>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com,
	"D. Jeff Dionne" <Jeff@...inux.org>,
	shumpei.kawasaki@...wc.com
Subject: Re: Moving forward with sh2/nommu

On Fri, 12 Jun 2015 00:12:52 +0900,
Rich Felker wrote:
> 
> On Wed, Jun 10, 2015 at 11:02:35PM -0500, Rob Landley wrote:
> > 
> > 
> > On 06/09/2015 10:30 PM, Rich Felker wrote:
> > > On Mon, Jun 01, 2015 at 11:11:07AM -0400, Rich Felker wrote:
> > >> [resent to musl list]
> > >>
> > >> Here's a summary of the issues we need to work through to get a modern
> > >> SH2/nommu-targetted musl/toolchain out of the proof-of-concept stage
> > >> and to the point where it's something people can use roughly 'out of
> > >> the box':
> > >>
> > >> Kernel issues:
> > >>
> > >> 1. Kernel should support loading plain ELF directly, unmodified. Right
> > > 
> > > I have a patch to do this, not polished but it works. It also...
> > > 
> > >> 2. Kernel insists on having a stack size set in the PT_GNU_STACK
> > >>    program header; if it's 0 (the default ld produces) then execve
> > >>    fails. It should just provide a default, probably 128k (equal to
> > >>    MMU-ful Linux).
> > > 
> > > ...uses a default stack size of 128k if the header is 0, and...
> > 
> > That's big enough to give a false sense of security without being big
> > enough to actually work reliably on software that isn't thinking about it.
> 
> It's the same size MMU-ful Linux gives you, and it works for the vast
> majority of applications. Of course with MMU you have the option to
> expand on faults, but I think the only application I've ever seen do
> this is emacs, and it typically only uses 164k. If you want to survey
> existing applications this is easy to do using busybox "top" in "s"
> mode, sorted by stack size. I wouldn't object to making the default
> slightly larger if measurement shows it's needed.
> 
> Keep in mind that the purpose here is running binaries which are _not_
> NOMMU-specific and not tuned for NOMMU. If your binaries are
> NOMMU-specific than you choose a proper stack size.
> 
> > The kernel stack size is apparently 4k, but they've got more than one
> > for different contexts:
> > 
> > https://www.kernel.org/doc/Documentation/x86/x86_64/kernel-stacks
> 
> Kernel stack is completely different. Userspace will not run with a 4k
> stack if you use libc in any nontrivial way.
> 
> > I think I agree to jeff here: the historical default stack size for
> > nommu packaging was 8k. That's enough for hello world to work, but in
> > this context stack is a resource we need to allocate if we want
> > nontrivial amounts of it.
> 
> That's doable (though still a bad idea, I think) as a default for a
> NOMMU toolchain. It's not okay for running a binary that's not made
> for NOMMU. This is not SH--specific but something that affects normal
> ELF binaries running on any NOMMU machine, and it's an issue I'm going
> to be adamant on, because adding the ability to do this with a huge
> security flaw is just irresponsible.
> 
> > >> 4. Syscall trap numbers differ on SH2 vs SH3/4. Presumably the reason
> > >>    is that these two SH2A hardware traps overlap with the syscall
> > >>    range used by SH3/4 ABI:
> > > 
> > > I haven't patched this yet. I'd like to use 31 (0x1f) as the new
> > > universal SH syscall trap number, instead of 22. More details on the
> > > reasons later.
> > 
> > I've cc'd Yoshinori Sato (who did most of the historical sh2 work) and
> > Shumpei Kawasaki (the original superh architect). They'll probably have
> > an opinion on your "more reasons" for changing sh2 system call numbers
> > to match sh4.

It histrical reason.
SH3/4 is assigned #0x10 to #0x17 for system call entry.
But SH2A system using this vector.
So we moved to #0x20 to #0x27 for SH2A.
(SH2A specification is #0x20 to #0x3f allocated for user application.)

And SH2 port is based on SH2A port.
It have same systemcall interface.

> Thank you. I'd really like to make progress at least on the matter of
> determining if this is feasible. I now have a new musl/sh2 patch that
> simply uses "trapa #31" unconditionally, and it's a lot
> simpler/cleaner and working on my patched kernel. The big question is
> just whether this is an unacceptable constraint on hardware.

SH2A reserved system for vector 31.
But not assigned now.
I think no problem.

> > >> musl issues:
> > >>
> > >> 1. We need runtime detection for the right trap number to use for
> > >>    syscalls. Right now I've got the trap numbers hard-coded for SH2 in
> > >>    my local tree.
> > > 
> > > I've written the runtime detection, but I'd rather not have to use it.
> > > I managed to avoid inlining a big conditional at each syscall, but
> > > there are still multiple ugly issues:
> > 
> > This is only an issue if you want sh4 to be able to run sh2 binaries.
> 
> Yes, and I've explained why this is important. In summary:
> 
> - It lets you do initial testing (or even native compiling) on the
>   MMU-ful variant of the target where you have things like memory
>   protection to assist you in debugging and the ability to use a lot
>   of software that wouldn't work on NOMMU.
> 
> - It fights the combinatoric explosion of configuration/target
>   variants that made uclibc so difficult to maintain by minimizing the
>   number of differences and by allowing regression testing without
>   specialized hardware (testing can be done on real hardware or on
>   qemu-system-sh4eb).
> 
> > (Can m68k run coldfire binaries? Last I checked there wasn't any
> > blackfin-with-mmu variant.)
> 
> As long as you use an ISA level that's a subset of both, there's no
> reason for it not to work. Demonstrating it without getting a common
> libc working on both would just be a matter of making a -nostdlib PoC
> program doing its own syscalls.
> 
> > > [...]
> > 
> > We should finagle together an XIP test setup. There were two different
> > people doing it at ELC we could ask questions of.
> 
> From the userspace side (libc/startfiles/toolchain/etc.) XIP should
> just work once we can make binaries in a format that allows for
> shareable text. XIP-capable hardware isn't really needed to test this
> side, just the kernel side.
> 
> > >> 2. We need additional runtime detection options for atomics: interrupt
> > >>    masking for plain SH2, and the new CAS instruction for SH2J.
> > > 
> > > This is the one thing I haven't done, so currently the atomic macros
> > > are using GUSA which is non-atomic and unsafe on SH2 (if an interrupt
> > > happens with invalid stack pointer, memory will be corrupted).
> > 
> > And doesn't work with SMP at all.
> 
> Right. I just added interrupt-masking-based atomics for SH2 on my
> side, but I know that's not useful for your SMP setups. It is useful
> for older non-SMP SH2 hardware, though.
> 
> > > This
> > > could be part of the random crashing I've been experiencing (although
> > > I reproduced it without musl) so I'll try to add them next.
> > 
> > I'm going to try to post kernel patches to the list later today, and
> > separately email you the horrible ethernet drivers that aren't going
> > upstream because horrible. (We need to clean up the ethernet VHDL too,
> > it has timing issues that randomly work or don't work because layout
> > butterfly effects. Known problem, on the todo list, not my area...)
> 
> OK thanks!
> 
> > >> 3. We need sh/vfork.s since the default vfork.c just uses fork, which
> > >>    won't work. I have a version locally but it doesn't make sense to
> > >>    commit without runtime trap number selection.
> > > 
> > > Done and updated to use runtime selection in the (ugly) patch.
> > 
> > If they ask for vfork() they should get vfork()...?
> 
> Yes. The "runtime selection" is about the syscall trap number, not
> whether or not to use vfork. I committed vfork to upstream musl now,
> but with a SH3/4 trap number to be consistent with the code that's
> upstream now. Later I'll either convert them all to trap 31 (0x1f) if
> that ends up being acceptable, or merge the runtime-selection code,
> but I think it makes sense to make the change across all files at
> once, whichever way it's done.
> 
> > >> 4. As long as we're using the FDPIC ELF header flag to get
> > >>    binfmt_elf_fdpic.c to load binaries, the startup code needs to call
> > >>    the personality() syscall to switch back. I have a local hack for
> > >>    doing this in rcrt1.o which is probably not worth upstreaming if we
> > >>    can just make the kernel do it right.
> > > 
> > > No longer needed because of the kernel patch to load normal ELF.
> > 
> > Send me the patch and I'll add it to my stack to go upstream.
> 
> It was attached, but it may need a little bit more cleanup before
> going upstream.
> 
> > >> 5. The brk workaround I'm doing now can't be upstreamed without a
> > >>    reliable runtime way to distinguish nommu. To put it in malloc.c
> > >>    this would have to be a cross-arch solution. What might make more
> > >>    sense is putting it in syscall_arch.h for sh, where we already
> > >>    have to check for SH2 to determine the right trap number; the
> > >>    inline syscall code can just do if (nr==SYS_brk&&IS_SH2) return 0;
> > > 
> > > Commit 276904c2f6bde3a31a24ebfa201482601d18b4f9 in musl solves this in
> > > a general manner, even though it's no longer needed with my kernel
> > > patch applied.
> > 
> > No longer needed on sh2 maybe, but there are a half-dozen other nommu
> > targets of interest...
> 
> The change is not sh-specific. This is in the fdpic elf loader code
> which is arch-generic. So if we can get the fix upstreamed, the issue
> won't matter on any future kernel versions, but it's still good for
> musl to be safe against being run on old kernels.
> 
> > > One more musl-side issue I neglected to mention is the __unmapself.s
> > > can't work on SH2 because the SH2 trap/interrupt mechanism requires
> > > the userspace stack pointer to be valid at all times. This is now
> > > solved upstream in commit c30cbcb0a646b1f13a22c645616dce624465b883,
> > > but activating it for SH2 requires removing
> > > src/thread/sh/__unmapself.s so the generic C file gets used.
> > > 
> > > The attached patch covers everything described above that's not
> > > already upstream, and is sufficient to build musl for sh2 with
> > > musl-cross targeting "sheb-linux-musl". I used gcc 4.7.3 because later
> > > versions break the kernel. The attached config.mak for musl shows the
> > > configure options I used. The attached sheb.specs file is how I got
> > > gcc to do always-PIE without breaking the kernel.
> > 
> > For the newly cc'd the relevant web archive entry is:
> > 
> > http://www.openwall.com/lists/musl/2015/06/10/1
> 
> Thanks!
> 
> Rich

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.