Patches for v109

[uazo]

Description

I will try again this time, hopefully with better results.
I have split the patches into different commits, so you can check them separately.

• v109 no code changes
  no changes, only porting to v109

• v109 no code changes (with macros to define base::Features)
  no changes, only porting to v109 (patches from Use helper macros to define base::Features #2507)

• v109 no code changes (with fix some lost changes after v108)
  no changes, but there are changes related to Fix some lost changes after v108 #2508

• v109 no code changes (with fix inverted Encode())
  no changes, but there are changes related to Patches for v108 #2471 (comment)

• v109 no code changes (big patches)
  this is the version before the first build, i.e. after the wiggle changes, but before my intervention. these changes, as they stand, lead to an unworkable build

• v109 no code changes (Update i18n zh_CN support)
  on this one, I'm sorry, I didn't waste my time. in the future I will try to make something easier to maintain

• v109 patches
  no changes except the deletion of defaults in CachedFeatureFlags, no longer needed by

• Remove CachedFeatureFlags#sDefaults
  https://source.chromium.org/chromium/chromium/src/+/aec86b4698c914db19b33fe3ea1b455cc4fb905f

• v109 Allow playing audio in background
  little fix

• v109 fix remove calling untrusted hooks
  no longer present, but, frankly, I don't think they are problematic

• v109 fix build (fixup)
  Here you will find the changes I had to make on the patches for the build.
  They are separate and need a fixup to fit into bromite, but you can check the only changes I had to make.

• v109 fix move navigation bar to bottom
  simple fix: replaced CachedFeatureFlags.isEnabled(flagname) with ChromeFeatureList.flagname

All submissions

• there are no other open Pull Requests for the same update/change
  unfortunately yes, but I will try to detail it for you
• Bromite can be built with these changes
  yes, but careful with bromite_patches_list.txt, which I did not touch
• I have tested that the new change works as intended (AVD or physical device will do)

Format

• patch subject and filename match (e.g. Subject: Alternative cache (NIK-based) -> Alternative-cache-NIK-based.patch)
• patch description contains explanation of changes
• no unnecessary whitespace or unrelated changes

[uazo]

I detect a problem in the apk in release mode (not debug), in my opinion related to the cfi check (gn flag is_cfi=true).
the error is a crash during startup:

Symbolizing stack using ABI: arm64
Build fingerprint: 'Xiaomi/gemini/gemini:8.0.0/xxxxxx:user/release-keys'
Revision: '0'
pid: 15693, tid: 15735, name: Thread-2  >>> org.bromite.bromite.dev <<<
signal 5 (SIGTRAP), code 1 (TRAP_BRKPT), fault addr 0x701896555c

Stack Trace:
  RELADDR   FUNCTION                         FILE:LINE
  v------>  std::Cr::DoIOSInit::DoIOSInit()  ../../buildtools/third_party/libc++/trunk/src/iostream.cpp:0:0
  v------>  std::Cr::ios_base::Init::Init()  ../../buildtools/third_party/libc++/trunk/src/iostream.cpp:157:22
  v------>  __cxx_global_var_init            ../../buildtools/third_party/libc++/trunk/src/iostream_init.h:2:31
  0000000003e5355c  _GLOBAL__I_000100                ../../buildtools/third_party/libc++/trunk/src/iostream.cpp:0:0

the crash also occurs on other devices.
I am trying to recompile with use_cfi_cast=false, unfortunately I know nothing about Control Flow Integrity, so I go by trial and error, then I will try disabling the cfi completely

[uazo]

I confirm that it was necessary to disable all cfi controls in order not to crash.
I am trying to read up on this to see if I can identify the best way to solve it.

for now I'm trying to figure out if the cause of the error is an improper DSO call, in which case I imagine the solution could be an incorrect visibility in some gn.
if i can't, i will start eliminating patch after patch to check which one is incorrect, starting with mine.

[uazo]

found it!

dlopen failed: cannot locate symbol "_Unwind_Backtrace" 

01-12 12:04:15.085 15548 15548 D AndroidRuntime: Shutting down VM
01-12 12:04:15.086 15548 15548 E AndroidRuntime: FATAL EXCEPTION: main
01-12 12:04:15.086 15548 15548 E AndroidRuntime: Process: org.bromite.bromite.dev, PID: 15548
01-12 12:04:15.086 15548 15548 E AndroidRuntime: fT0: errorCode=4
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at Ag.B(chromium-ChromePublic.apk-stable-541408015:4)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at bz0.a(chromium-ChromePublic.apk-stable-541408015:70)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at ug.run(chromium-ChromePublic.apk-stable-541408015:5)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at android.os.Handler.handleCallback(Handler.java:883)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:100)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:214)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:7356)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:940)
01-12 12:04:15.086 15548 15548 E AndroidRuntime: Caused by: fT0: errorCode=2
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at org.chromium.base.library_loader.b.g(chromium-ChromePublic.apk-stable-541408015:127)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at org.chromium.base.library_loader.b.b(chromium-ChromePublic.apk-stable-541408015:11)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at org.chromium.base.library_loader.b.a(chromium-ChromePublic.apk-stable-541408015:8)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at tg.run(chromium-ChromePublic.apk-stable-541408015:13)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at java.lang.Thread.run(Thread.java:919)
01-12 12:04:15.086 15548 15548 E AndroidRuntime: Caused by: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_Unwind_Backtrace" referenced by "/data/app/org.bromite.bromite.dev-ikpkY8EUfsdDKIbq-BR48Q==/lib/arm64/libclang_rt.ubsan_standalone-aarch64-android.so"...
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at java.lang.Runtime.load0(Runtime.java:938)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at java.lang.System.load(System.java:1631)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at org.chromium.base.library_loader.b.j(chromium-ChromePublic.apk-stable-541408015:131)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        at org.chromium.base.library_loader.b.g(chromium-ChromePublic.apk-stable-541408015:43)
01-12 12:04:15.086 15548 15548 E AndroidRuntime:        ... 4 more

[uazo]

I stand corrected, I finally found the right way.
this the error:

01-12 17:31:09.554  7642  7685 I org.bromite.bromite.dev: ../../buildtools/third_party/libc++/trunk/include/__std_stream:76:5: runtime error: control flow integrity check for type 'std::__stdinbuf<char>' failed during virtual call (vtable address 0x007429cd2ad4)
01-12 17:31:09.554  7642  7685 I org.bromite.bromite.dev: 0x007429cd2ad4: note: invalid vtable
01-12 17:31:09.555  7642  7685 I org.bromite.bromite.dev:   0c b4 0d 00 24 48 0d 00  c4 71 08 00 f4 71 08 00  b4 48 0d 00 cc 48 0d 00  e4 48 0d 00 fc 48 0d 00
01-12 17:31:09.555  7642  7685 I org.bromite.bromite.dev:               ^
01-12 17:31:09.619  7642  7685 I org.bromite.bromite.dev: SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../buildtools/third_party/libc++/trunk/include/__std_stream:76:5 in
01-12 17:31:09.620  7642  7685 F libc    : Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 7685 (Thread-3), pid 7642 (ite.bromite.dev)

[uazo]

I fixed that problem, but many many others are arising, too many to be linked simply to the transition to 109, also because they are linked to the chromium code, in parts that we have not touched.
don't really know how to proceed, I'm almost inclined to think that cfi is not really applied in any bromite builds...
I would also need you to try the build to see if it is a problem with my ci

[uazo]

for the record (and not to drive you crazy searching for the problem, which took me a week), the crash is related to the clang flag -fexperimental-relative-c++-abi-vtables that you have to manually delete from the gn (build/config/android/BUILD.gn) when compiling with is_cfi=true, at least until we get to the revert. see https://bugs.chromium.org/p/chromium/issues/detail?id=589384 and also https://bugs.chromium.org/p/chromium/issues/detail?id=1375035#c57

[csagan5]

Thanks for the heads-up, I will try with use_relative_vtables_abi=false when is_cfi is true.

[csagan5]

Thanks for the heads-up, I will try with use_relative_vtables_abi=false when is_cfi is true.

That is a dead-end, use_relative_vtables_abi is internal; perhaps I will revert chromium/chromium@70aed9d instead.

[csagan5]

I have split the patches into different commits, so you can check them separately.

I will go through them commit-by-commit, thanks. The PR already shows conflicts but ignore them, they are not real conflicts.

[uazo]

perhaps I will revert chromium/chromium@70aed9d instead.

it is a pity that it does not work with cfi, because the idea of relative vtables is interesting and has security implications. see https://llvm.org/devmtg/2021-11/slides/2021-RelativeVTablesinC.pdf
according to the chromium team, the cause is an incorrect use of the gn arguments we use, but I did not understand (accidendi al mio inglese!) whether this is our fault or theirs.

I was able to reproduce a small test case that allows me to check the crash without having to recompile all of chromium, so I am looking for what the argument leading to the crash might be.

Incidentally I see that there are some arguments we use that are probably not very correct, such as use_sysroot=false which could cause the build to use the wrong toolchain, but I will open a separate issue.

it was also lucky (!) that the vanadium team didn't tell us anything about the crash (they already noticed it in december) because, before the chromium team told me, i figured out how to check manually the changes in the build between majors and also that there is a custom libc++ in chromium (which would probably allow us to insert some grapheneos security patches) and that the crashpad handler is actually an executable masquerading as a library, and it could be useful to those who (aragore, agore ?? I can't find the discussion anymore) had proposed to insert an internal proxy as an executable.

[uazo]

ah, also saw that we could probably reduce the apk size by deleting a large part of the elf table, like chrome does. we would lose the stack trace in the logcat, but most of the time it's useless and we can rebuild it with the crash file. I will try sooner or later.

[uazo]

oh, one more thing! we can probably fix AImageReader crash by editing the cfi/ignores.txt file.
the more time passes, the more I realize how much I don't know about the chromium universe, and that scares me a little...