[Toybox] [PATCH] blkdiscard (for review)

Tue Apr 14 16:36:51 PDT 2020

On Tue, Apr 14, 2020 at 4:34 PM Rob Landley <rob at landley.net> wrote:
>
> On 4/13/20 6:23 PM, Patrick Oppenlander wrote:
> > On Fri, Apr 10, 2020 at 5:33 PM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 4/9/20 12:54 AM, Patrick Oppenlander wrote:
> >>> Hi Rob,
> >>>
> >>> I needed blkdiscard for an embedded job so had a go at putting it together.
> >>
> >> Applied, let's see...
> >>
> >>> Length & offset parsing don't match util-linux where MB, GB are powers
> >>> of 1000 and M, MiB, G, GiB are powers of 1024.
> >>>
> >>> I didn't use xioctl to avoid leaking fd if CFG_TOYBOX_FREE is set. Is
> >>> there a better solution to this?
> >>
> >> CFG_TOYBOX_FREE is... squishy.
> >>
> >> In theory there's no point freeing memory and closing files right before a
> >> program exits, because the process is about to go away and the OS will clean all
> >> that up. But the android guys like running stuff under valgrand and such to find
> >> resource leaks (even when they don't necessarily matter). There are long-running
> >> programs that shouldn't leak (if "sed" leaked memory for each line of input it
> >> processed it would run out of memory handling a large enough input file), but
> >> something like nice/sleep/nproc/mount/insmod ever freeing memory is kind of
> >> optional.
> >
> > Totally agree. In my opinion there's only one argument for commands
> > like blkdiscard cleaning up: integration with the toybox shell to
> > avoid fork/exec on NOMMU to reduce memory use.
>
> Eh, having access to basic capabilities from a "kernel plus one userspace
> package" base is nice. But a separate command for every ioctl in the world is
> kinda sad. (This is why I like /proc and /sys knobs: echo thingy >
> /some/control/knob avoids the need for a special command to do that.)
>
> > 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?

I thought the point of a single multi-call was that the total is less
than the sum of the parts?

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

> > So arguably simple is best. Would you like me to change it?
>
> I'm already fiddling with it here, but... hmmm.

I sent a simple patch to clean up the error return paths before you
sent this. Feel free to ignore it and do your magic :)

> I have automatic atolx parsing in optstr with # instead of : BUT it stores the
> result in a long which means on 32 bit systems them maximum value is 2 gigs, and
> this combines badly with large file support.
>
> On 64 bit systems, # is obviously the right thing to do. But when supporting 32
> bit systems with large block devices, what you're doing (save the string then
> parse in main) is the right thing to do.

I saw the # support in optstr. That reminds me -- I made a note that
the Toybox M/MB/MiB parsing doesn't match blkdiscard where MB is *1000
and M, MiB are * 1024. I overlooked that you have the 'd' support for
decimal sizes so I guess that's intentional and consistent across all
commands which take size arguments?

Supporting powers of 1000 here is useless anyway. The offset & length
need to be aligned to the underlying device block size, which, for all
devices I know of is a power of 2.

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

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.

> Oddly enough, 32 bit embedded systems using VFAT filesystems generally don't
> have large file support, so the size limit doesn't come up in the embedded world
> as often as you'd think. But large BLOCK devices are pretty common. (The new sd
> card standard goes to 128 terabytes, and while I have yet to see them in the
> wild it's getting hard to find 4 gig cards anymore.)
>
> My previous poster child for this dilemma was "truncate -s". I had previously
> erred on the side of optimizing for 64 bits (even embedded systems are often 64
> bit at this point because it's cheap, we haven't pulled the trigger on 64 bit
> j-core yet but it's only a matter of time). But I'm reluctant to _break_ one
> that works, and it's a trivial amount of extra code...
>
> >> MY fix is to make a system small and simple enough that a sufficiently trained
> >> group of professional reverse engineers can make it through "objdump -d" of the
> >> whole thing in a reasonable amount of time, and then build the system under that
> >> known good base. (This is what the Norad guys were doing in the video in (B)
> >> which his why they were using the smallest and simplest implementations they
> >> could find for high-security systems.) And we're doing the hardware side of that
> >> over at https://j-core.org.)
> >
> > Thaks for the writeup, that's a mind bending concept.
>
> Did you know that if somebody sufficiently reprograms a modern wifi chip it can
> act like a radar to track where people physically are in signal range, and watch
> them move around in realtime?
>
> https://gizmodo.com/scientists-are-turning-wifi-routers-into-creepy-radar-c-1794961990
>
> https://www.zdnet.com/article/hundreds-of-millions-of-cable-modems-are-vulnerable-to-new-cable-haunt-vulnerability/
>
> Phones are _way_ bigger targets. People do banking through these things, carry
> around a GPS tracker with a microphone that can hear the whole room (how else
> does "speakerphone mode" work?) and point a high resolution video camera at
> their own face for extended periods of time. Voluntarily! (Oh yeah: and they
> have modern high-end wifi too.)
>
> Securing them is kind of important.
>
> The android guys refer to the "evil butler" problem (presumably because "evil
> maid" was considered sexist?) where somebody gets ahold of your phone for half
> an hour and suddenly you're carrying a GPS tracking always-on microphone with a
> camera around with you 24/7. This is why everything is crypto-signed chain of
> custody, unlocking the bootloader requires a factory reset (because "all my apps
> are gone" is not as subtle unnoticed change), and an unlocked phone with a
> non-stock image boots in a visibly different way.
>
> But that's just ONE axis of potential suckage. (Start peeling this onion and you
> eventually get to selective doping attacks against asic manufacturing where you
> can backdoor a chip in a way that doesn't show up when you decap it. But there's
> not a lot I can do about that in software, and I'm not sure how much worse
> outsourcing manufacturing to a country that doesn't actually like us because the
> labor's cheap would be than having it here where the NSA can get at it? Besides,
> no ATTACK is going to be worse than what Intel and Arm and such have been
> DESIGNING INTO the things.
>
> No, not spectre and meltdown. That's old news (although yes, arm had its own
> variants). What have we had so far _this_ year...
>
> https://arstechnica.com/information-technology/2020/03/5-years-of-intel-cpus-and-chipsets-have-a-concerning-flaw-thats-unfixable/
> https://arstechnica.com/information-technology/2020/03/hackers-can-steal-secret-data-stored-in-intels-sgx-secure-enclave/
> https://www.tomshardware.com/news/new-amd-side-channel-attacks-discovered-impacts-zen-architecture
> https://www.tomshardware.com/news/load-value-injection-vulnerability-found-in-intel-chips

Thanks for all the references. I'll add them to my reading list.

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

> Me, I'm a software guy. I'm 2700 lines into writing a hopefully 3500 line bash
> replacement, months late on cutting a release, and feeling REALLY GUILTY I
> haven't written a status update for my 11 supporters on
> https://patreon.com/landley but I'm trying to get to a checkpoint I can report
> as progress. I've ALMOST got "make root" booting to a shell prompt through the
> init script...

I know words of encouragement are less value than Patreon $, but,
thanks for all your hard work!

Patrick