< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18098: scripted-diff: Add missing spaces in RPCResult, Normalize type names (master...1912-rpcDocFixes) https://github.com/bitcoin/bitcoin/pull/18098
< bitcoin-git>
[bitcoin] luke-jr opened pull request #18165: Consolidate service flag bit-to-name conversion to a shared serviceFlagToStr function (master...svcflags2str) https://github.com/bitcoin/bitcoin/pull/18165
< jonasschnelli>
Oh. I can macOS notarize the 0.19.1rc2 binary
< jonasschnelli>
"message": "The executable does not have the hardened runtime enabled.",
< fanquake>
jonasschnelli: likely need some additions to a .plist somewhere
< jonasschnelli>
Probably... strange it worked with rc1?!
< fanquake>
Interesting
< jonasschnelli>
maybe they (Apple) just started to enforce it? dunno
< fanquake>
I think that might be the case, was just trying to find the dates
< fanquake>
Although we can add that to our tree with the other macdeploy files
< jonasschnelli>
fanquake: I guess we need `--options runtime` during codesign
< jonasschnelli>
(detached-sig-create)
< jonasschnelli>
fanquake: would be nice if you can investigate further and PR. We can make a testbuild for rc2 and make sure we land in rc3 or final
< fanquake>
Sure. I can take a look at some changes.
< wumpus>
FWIW I'm not going to be at bitcoin 2020 / coredev next month, sorry, even less eager than normal to go on a long flight like that with the coronavirus and quarantaine scare
< jonasschnelli>
I won't be there as well...
< wumpus>
I don't have a good feeling about this tbh
< promag>
wumpus: keep calm and enjoy merging #13339
< promag>
I'm planning to move the timer from walletmodel(s) to wallet controller, and move the calls to the background thread
< wumpus>
makes sense
< promag>
but that's a bigger change and I think 18160 improves a lot cpu usage and is an easy backport
< promag>
let's see what jonasschnelli and ryanofsky say
< luke-jr>
wumpus: does RISC-V need #17569 backported? (why not?)
< gribble>
https://github.com/bitcoin/bitcoin/issues/17569 | build: Allow export of environ symbols and work around rv64 toolchain issue by laanwj . Pull Request #17569 . bitcoin/bitcoin . GitHub
< wumpus>
luke-jr: couldn't hurt at least
< luke-jr>
wumpus: well, it means a rc3... :/
< luke-jr>
wumpus: if the rc2 binaries work on RISC-V as-is, then we don't need it in 0.19.1 at least
< luke-jr>
(IIRC you have a RISC-V system to test on, right?)
< luke-jr>
(to be clear, it's the noexecstack commit that I'm unsure about - obviously gitian builds complete ;P)
< dongcarl>
What's the current thinking on running Bitcoin Core on non-ECC devices? Are there enough safe guards in place so that at least casual users can use non-ECC devices?
< sipa>
what is a non-ECC device?
< sipa>
elliptic curve crypto?
< sipa>
error correcting code?
< dongcarl>
devices without ECC RAM haha
< luke-jr>
I suspect most people do
< luke-jr>
IIRC Intel doesn't even allow you to use ECC with their normal CPUs
< rafalcpp>
dongcarl: almost all users sadly sit on non-ECC RAM. and you have no idea what will bitflip, it could be disk driver that will erase wallet or whatever. probably rather pointless to defend in software
< sipa>
is there *any* consumer oriented CPU that supports ECC?
< rafalcpp>
sipa: pretty sure AMD Bulldozer supports, for example
< luke-jr>
rafalcpp: there are places we *should* definitely defend.. your backups won't help you if you bitflip a change address
< luke-jr>
sipa: POWER9
< luke-jr>
(not typical, but the 4-core variants are consumer-oriented)
< rafalcpp>
2-of-2 multisign on other, cheap, device would solve it basically, although much less comfortable to use, dongcarl. an idea for future when it becomes non-trivial amount
< luke-jr>
dongcarl: I don't know :/
< dongcarl>
rafalcpp: Right, I think the fact that usable SBCs are getting cheaper and cheaper is great. However, setting up clusters is quite a pain still
< dongcarl>
Another question: When testing out lower-power SBCs, what's a good metric for "runs Bitcoin Core well"? Is "being able to keep up with tip" good enough?
< luke-jr>
dongcarl: IBD in an hour? :P (haha)
< yevaud>
dongcarl: even on the upper end SOCs IBD takes days.
< yevaud>
dongcarl: the cheapest "sbc" with ECC is almost certainly the APU2/APU4, it's still slow and fanless, like any other SBC.
< dongcarl>
Disregarding IBD I mean... In a steady state, is there anything else that would hinder correct operation and security other than keeping up with tip?
< dongcarl>
yevaud: right, from my understanding the apu2 might be affected by PSP, but I'm not sure that the NICs will cooperate if someone wants to attack
< yevaud>
not really. on most SBCs you're going to see rather high rates of data loss due to MicroSD cards, but they run acceptably in the sync state.
< dongcarl>
luke-jr: Did you get to look at the apu2 architecture and evaluate the risks closely?
< rafalcpp>
dongcarl: a cluster? just run two separate instances. If anything is needed, I suppose bitcoind/gui could support 2-2 multisign more easily (if it doesn't yet)
< yevaud>
dongcarl: yes, it has a PSP core.
< luke-jr>
dongcarl: no
< luke-jr>
dongcarl: I saw AMD and closed it
< dongcarl>
yevaud: Right, but what's the exact attack though? From my understanding you'd need the NICs to cooperate, and PSP isn't in the coreboot payload that PC Engine builds...
< dongcarl>
rafalcpp: That's true, you could probably do some deduplication at the FS level to save some space too
< rafalcpp>
dongcarl: well this isn't separate computer then. but just fully prune one (or both) then it is around 6 GB
< yevaud>
dongcarl: I don't know without asking PcEngines (do, they're helpful), but I don't think it's a realistic concern in the real world.
< luke-jr>
I'm not sure PcEngines would know either?
< dongcarl>
yevaud: That's a good point. Will email.
< luke-jr>
dongcarl: but afaik the PSP is inivislbe outside the CPU?
< yevaud>
luke-jr: on the Intel one it's stored on an external flash chip.
< luke-jr>
but at least on Intel, if you deprive it, it won't work
< yevaud>
stands to reason the manufacturer would have to understand that, if it were the case on AMD.
< * dongcarl>
has some reading to do
< luke-jr>
yevaud: they might not understand the ramifications of not providing it, even if that is the case
< luke-jr>
eg, on Intel the IME is used to workaround silicon bugs, so with me_cleaner and such, you're vulnerable to undisclosed vulnerabilities
< yevaud>
uh, really? the microcode is a separate thing to the ME core.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #18166: ci: Run fuzz testing test cases under valgrind (master...fuzz-test-cases-under-valgrind) https://github.com/bitcoin/bitcoin/pull/18166
< luke-jr>
yevaud: someone disclosed or leaked that a while ago. it's not just microcode that patches silicon issues.
< luke-jr>
I don't know that any of the specific details of the silicon bug were disclosed, so we can only speculate on why Intel might have done ti that way
< luke-jr>
(maybe it's a silicon issue with the ME core, and not patching it means external attackers can compromise the ME core?)
< dongcarl>
(if this is off-topic, someone should let me know)
< dongcarl>
luke-jr: I think the PSP firmware has to be in the BIOS to be loaded
< yevaud>
luke-jr: I was under the impression that ME operations against the main cores were effectively a NMI, so having it do any sort of continuous operation would demolish performance.
< yevaud>
luke-jr: but obviously I don't have specific knowledge here, so I'll leave it at that.
< luke-jr>
yevaud: I'm not sure why that would matter. Injecting a bit of code wouldn't need to be continuous, and most things can be done by reading/changing RAM directly
< wumpus>
luke-jr: they work fine without the patch, #17569 does work around a noexecstack issue (so the stack is executable), I don't think it's worth doing a new rc for but if there is one anyway we could include it
< gribble>
https://github.com/bitcoin/bitcoin/issues/17569 | build: Allow export of environ symbols and work around rv64 toolchain issue by laanwj . Pull Request #17569 . bitcoin/bitcoin . GitHub
< dongcarl>
Does anyone know how to setup gribble for another channel? I'm thinking #bitcoin-builds
< bitcoin-git>
[bitcoin] TheQuantumPhysicist opened pull request #18167: Fix a violation of C++ standard rules where unions are used for type-punning (master...master) https://github.com/bitcoin/bitcoin/pull/18167