[Toybox] [PATCH] blkdiscard (for review)

[Patrick Oppenlander]

On Wed, Apr 15, 2020 at 11:48 AM Rob Landley <rob at landley.net> wrote:
>
> On 4/14/20 6:36 PM, Patrick Oppenlander wrote:
> >>> Without FDPIC every
> >>> toybox fork/exec requires a another copy of the entire program image
> >>> which kinda sucks.
> >>
> >> Run "make change", then look in the "change" directory.
> >>
> >> (It's "change for a $20". There should probably be be a better name for it.)
> >
> > What's the use case for the separate binaries?
>
> Mostly that people complain about not having it, but on a nommu system without
> fdpic or binflt (which in my case means static PIE) you load less in for each
> binary that can't share anything with any other binary.

Of course. That makes more sense now :)

> >>> Then again, FDPIC for ARM should be available in gcc 10 (& musl
> >>> hopefully soon after) which ought to cover the majority of that space.
> >>
> >> Oh hey. Those french guys finally got their stuff pushed upstream? (I poked Rich
> >> about that 4 years ago, https://www.openwall.com/lists/musl/2016/12/13/2 but he
> >> decided to wait for it to wind up in the upstream compiler before caring. He has
> >> a contract to maintain the fdpic stuff for sh2 and had the concepts explained to
> >> him by Jeff Dionne the original author of uClinux, so the base support is there.
> >> But there wasn't much he could do about the compiler...)
> >
> > Yep, looks like it went in September 2019.
> >
> > FDPIC for ARM is also on the musl 1.2.2 roadmap
> > https://wiki.musl-libc.org/roadmap.html aimed for June release.
>
> Cool. For cortex-m scripts/mcm-buildall.sh is doing
> "armv7m:eabi:--with-arch=armv7-m --with-mode=thumb --disable-libatomic
> --enable-default-pie" which provides a compiler I can then "make root
> CROSS=armv7m" which makes static pie binaries that qemu-arm -cpu cortex-m3 can
> sort of run?
>
> $ qemu-arm -cpu cortex-m3 root/armv7m/fs/bin/toybox echo hello world
> hello world
>
> But not reliably:
>
> $ qemu-arm -cpu cortex-m3 root/armv7m/fs/bin/toybox cal
> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
> Illegal instruction
>
> (Without the -cpu it runs fine. Something toolchainish I suspect? I don't THINK
> an unaligned access issue would cause illegal instruction and sh4 should catch
> that anyway.)

│  >0x7ff9b00a  mrc 15, 0, r4, cr13, cr0, {3}

It's because armv7-m is missing a hardware TLS register. I guess
qemu-user doesn't know how to handle that.

The way I handle it is trap and emulate. My employer has a custom RTOS
with a minimal linux compatible syscall interface (forked from
http://prex.sourceforge.net and heavily modified) which I maintain. I
have convinced them to open source it, it's just waiting for me to get
my shit together and sort out licensing & copyright issues.

We will probably end up using your 0BSD license. Currently trying to
figure out the best places to put copyright notices. Do you have any
advice on that topic?

> But the main reason I haven't put more work into that target is I haven't got a
> kernel config and qemu-system-arm -M cortex-m-board pair I can use yet. The
> cortex-m board I (briefly) had to run Linux on was an expensive FPGA thing
> Innoflight loaned me for a bit, but took back again last year. (It had a
> cortex-m bolted to the side of the FPGA. The kernel for that was an out-of-tree
> fork maintained by Emcraft in Moscow, and all the make root tagets are vanilla
> kernel with no patches.)

I use the mps2-an385 (which is cortex-m3) board for my (non linux)
testing. There's a .dts for it in the mainline linux kernel, but I've
never tried to run it.

> > That's another confusing thing with blkdiscard. The official
> > documentation says "The provided value will be aligned to the device
> > sector size." which I interpreted as meaning that the code would align
> > an offset of 99 to something sane. But, do you round down or up? So I
> > tried the one installed on my Arch Linux system and:
> >
> > % blkdiscard -o 99 /dev/sdc
> > blkdiscard: /dev/sdc: offset 99 is not aligned to sector size 512
>
> The man page says Lukas Czerner ⟨lczerner at redhat.com⟩ maintains it, so I guess
> ask him which way to go? (I'd say "pick one" but if this is a security thing you
>  want to err on the side of removing data, and if it isn't you'd want to err on
> the side of KEEPING data, and I have no idea?)
>
> If he doesn't reply, I guess err on the side of removing data? If you were told
> to discard data in this block, that means discarding the whole block. Otherwise
> blkdiscard with a 1 byte range is a NOP...
>
> > I didn't bother with testing for that case as the kernel spits the
> > dummy if you give it stupid numbers anyway, so I didn't see the point
> > of the extra ioctl to find the block size and the extra code to
> > duplicate tests the kernel does anyway.
>
> Also a valid approach. Possibly the fix that needs to go into Lukas' version is
> a change to the man page to stop claiming it does something it doesn't. :)

To me that seems like the best answer. I'll ask.

> >> And so on, and so forth... Eh, I'm sure it'll be fine. Never caused a problem
> >> before. That we know about. (In case you're wondering why my $DAYJOB is with
> >> people who made their own processor from scratch... There's reasons for it.)
> >
> > I love the idea of J-Core. Is there readily available silicon now or
> > do you still run on FPGA?
>
> We still run on an FPGA. We met with some chip fab guys from Taiwan the
> _morning_ we flew out of Japan due to Coronavirus back in February. (They sat 6
> feet away from us. I mentioned it briefly in
> https://landley.net/notes-2020.html#18-02-2020 .) Right now we're just trying to
> survive the pandemic.
>
> On the bright side, the ICE40 version now builds a working bitstream with an
> entirely open source toolchain (the
> https://lists.j-core.org/pipermail/j-core/2019-November/000868.html guys finally
> got enough bugs fixed, although I need to finish unifying the j1 and j2 trees
> and push that to github, what's up there now still only builds with the lattice
> tools because we had to rewrite the register file to get the new toolchain to
> recognize it's a RAM and not a pile of flip-flops. New one's a lot cleaner
> anyway, but the commit's not against the old tree...)

That's fantastic!

Patrick