[Toybox] [PATCH] Addition of the 'g' command to vi.c

[enh]

On Wed, Oct 11, 2023 at 2:08 AM Rob Landley <rob at landley.net> wrote:
>
> On 10/10/23 12:52, enh wrote:
> >> In theory ASAN should be able to spot that one! In practice, if it's a local
> >> variable on the stack, not so much.
> >
> > you can add `-ftrivial-auto-var-init=pattern` to your CFLAGS.
>
> $ CFLAGS="-ftrivial-auto-var-init=pattern" ASAN=1 make clean defconfig tests
> ...
> cc: error: unrecognized command line option '-ftrivial-auto-var-init=pattern'
>
> The host compiler is gcc 8.3.
>
> $ CROSS_COMPILE=ccc/x86_64-linux-musl-cross/bin/x86_64-linux-musl-
> CFLAGS="-ftrivial-auto-var-init=pattern" ASAN=1 make clean defconfig tests
> ...
> x86_64-linux-musl-cc: error: unrecognized command-line option
> '-ftrivial-auto-var-init=pattern'
>
> The cross compiler is gcc 11.2, Looks like this is an llvm-only thing.

no, it's just that gcc really dragged their feet on this one. llvm's
had this for so many years i can't remember, but gcc only added it in
GCC 12 (?) [citation:
https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/1972043].
funnily enough, gcc added it without the stupid
`-fboo-hoo-this-isn't-officially-sanctioned-by-wg14-wah-wah-wah`
nonsense that clang had, which made clang drop that. so that was nice.
(yeah, sure it's a different dialect. but it's a _better_ dialect, so
you can stick that up the same "unspecified" pipe you're so used to
beating us with and give us something that actually helps quality for
once!)

> Which I'm happy to test, but I need to do the next cleanup pass to get "make
> tests" to pass building with the NDK. Or maybe the next round of wrestling with
> the llvm-hexagon compiler, but running the test suite under qemu applicatioon
> emulation is creepy and they still haven't published a full qemu-system-hexagon
> for the comet board yet:
>
> https://www.openwall.com/lists/musl/2023/09/27/4#:~:text=qemu-system-hexagon
>
> Nobody else HASN'T got a gcc+glibc for their architecture (modulo a couple
> really tiny chips stuck on the corpse of uClibc, but they were still gcc), so
> they don't put nearly as much effort into maintaining llvm toolchains, let alone
> llvm+musl ones. (I miss http://ellcc.org/ but it was last updated in 2017 and I
> worked with its maintainer at JCI in 2018, and that job kept him WAY too busy to
> work on ellcc. I _did_ explain to him why extracting all the source packages and
> checking everything in to one big source control repository with your own
> changes on top of the external files you'd checked in was NOT IDEAL, but he
> never got around to redoing it...)
>
> > (Android
> > globally always uses -ftrivial-auto-var-init=zero because,
> > surprisingly, it has better security properties than pattern. it's
> > also better for code size etc.)
>
> Sounds interesting, but I have no context to understand why you'd make what
> decisions here. (The pattern is poisoning with a known value? And the other one
> either disables the init or initializes it with zero? I thought the OS already
> initialized freshly allocated memory with zeroes.

sure, but this is the _stack_ we're talking about. it's clean the
_first_ time round, but...

basically they insert an `= 0` for everything, and let the optimizer
throw away the useless ones. it costs surprisingly little in correct
code (according to our numbers across all of Android) and saves your
ass in incorrect code (we've seen actual examples; this is also where
the "pattern is less useful than zero from a security perspective"
comes from; if you don't care about exploitability and just want to be
more likely to trip over bugs, you'll prefer pattern).

(devices using the scudo allocator do also do the "malloc() is
calloc()" thing. we're still working on getting rid of jemalloc at the
low end.)

> Whatever DID happen with the
> zero page, anyway? They stopped it from being an actual page with a reference
> count way back when because A) there was contention for the counter, B) the
> counter managed to wrap and free the page on some enormous system, which was
> Suddenly Very Bad. But that was YEARS ago, before most of the huge page work I
> think? Mel Gorman still seems to be around, he acked a patch in August, so I
> assume it's all being reasonably managed, but beats me what they're up to...)
>
> Anyway, I was thinking more like whatever caused commit 472599b99bec to ls. In
> theory there's a tool that gets mad about reading from memory nothing ever wrote
> to. Maybe it was valgrind? I don't want to run it _every_ time, but the
> occasional pass might be interesting...
>
> Rob