[Toybox] [PATCH] blkdiscard (for review)

Mon Apr 13 23:40:43 PDT 2020

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

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

> So arguably simple is best. Would you like me to change it?

I'm already fiddling with it here, but... hmmm.

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.

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

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

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

> Patrick

Rob