<cyrozap>
mithro: Be aware that picotcp is GPLv2 _only_, while lwip is modified BSD
<mithro>
GPL v2 only is such a pain but we are reusing a bunch of Linux stuff, so already have to deal with that.
<sb0>
mithro, where is it a pain exactly?
<mithro>
sb0: It's a pain when you want to use GPLv3 and GPLv2 only code together
early has quit [Ping timeout: 248 seconds]
early has joined #m-labs
early has quit [Read error: Connection reset by peer]
early has joined #m-labs
sandeepkr has quit [Read error: No route to host]
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
sandeepkr has joined #m-labs
<whitequark>
llvmlite is written by idiots, issue #15: it doesn't actually understand the namespaces of LLVM
<whitequark>
like seriously did any of those people read the fucking reference
<rjo>
whitequark: less whining please
key2 has joined #m-labs
<whitequark>
more competently written code, please.
evilspirit has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<hozer>
interesting
<hozer>
I was just ranting about security and why all compiled code should be signature-checked by the CPU before execution
<hozer>
but how does one do this with an actually useful JIT like numba might be
<whitequark>
Apple devices have no JIT available to apps.
<whitequark>
so... one doesn't.
<hozer>
apple devices also have schrodinger's security. It's either pre-hacked by the NSA, or so strong the FBI can't break it
<hozer>
in theory, I find the no-JIT to be something that seems like a good security practice
<whitequark>
apple devices are probably the best protected off-the-shelf devices on market
<hozer>
in practice... it's still one huge binary blob that I have no idea who actually has the signing keys for
<whitequark>
as for FBI, that particular iPhone doesn't have Secure Enclave, so bruteforcing the PIN is straightforward
<whitequark>
just back up the NAND and reflash after exhausting all attempts
<hozer>
right
<hozer>
but at some point if Apple is actually protecting their bottom line by locking out clones they are also locking out court-ordered law enforcement access
<whitequark>
uh
<whitequark>
they deliberately lock out law enforcement access.
<whitequark>
haven't you seen their court filings? they rail pretty hard against the idea of a backdoor
<hozer>
it's brilliant PR & marketing
<whitequark>
it isn't. secure backdoors don't exist
<hozer>
but as soon as there's a law enforcement backdoor some guy with connections to both a local judge and an offshore phone factory will get the backdoor
<hozer>
which, to me, is the fundamental business case why Apple is actually doing something usefull in fighting backdoors
<whitequark>
same thing
<whitequark>
the second reason is that the moment the US LE gets a backdoor, everyone else will also want in.
<hozer>
yep
<hozer>
but back to JITs.. how do you make a secure one? Or are we stuck with porting everything to C/C++
<whitequark>
I don't think JITs ultimately matter here
<whitequark>
disabling JITs is an ad-hoc mitigation that removes probably the most common class of weird machines
<whitequark>
that is, disabling JITs makes it harder or impossible to exploit other classes of bugs
fengling has joined #m-labs
<hozer>
yes, so in practice, it becomes a lot easier to validate, both statically, ahead of time, and at runtime that you're running what you think you are running
<hozer>
if you allow JITs and self-modifying code, there are now all kinds of obscure bugs that can be exploited
<hozer>
and the bugs in LLvmlite are either cause the developers don't understand, or because it's intentionally inserting more attack surface for future exploits
<whitequark>
what
<hozer>
so let's say 99% of what looks like incompetence is just plain incompetence
<hozer>
but there's some amount that looks incompetent, but is actually a way to deploy Stuxnet
<hozer>
... a perfectly acceptable response is "your paranoia has gone off the deep end"
<whitequark>
lemme just politely stay silent on that part
sb0 has quit [*.net *.split]
mwalle_ has quit [*.net *.split]
<hozer>
well, I sat through one too many counterintelligence briefings after which I decided I only ever want to work on stuff I can always talk to anyone about
<hozer>
so let's just assume incompetence. LLVM is so hugely complicated, and the lite version apparently doesn't understand what it's doing
<whitequark>
llvmlite is just bindings
<hozer>
so if you want to write in python, is there any way to statically compile the stuff that needs to be fast?
<whitequark>
short answer: no.
<hozer>
When's the last time you worked with fortran code
<hozer>
there's all this computational chemistry (and weather models for that matter) that have been validated in fortran, but the cost to re-validate a new 'modern' implementation would be damn near impossible
sb0 has joined #m-labs
mwalle_ has joined #m-labs
<whitequark>
never used fortran
<whitequark>
but i imagine this is what's keeping dragonegg alive
key2 has quit [Ping timeout: 244 seconds]
<hozer>
hrrm
<hozer>
how exactly does that work with the licensing
<hozer>
dragonegg is gpl, right? I suppose it links with libllvm which is mit/bsd-ish right?
<hozer>
and yes, I think fortran is a large contributor to why llvm-gcc and dragon-egg exist in the first place
<whitequark>
yeah
evilspirit has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Ping timeout: 276 seconds]
rohitksingh has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
rohitksingh has quit [Ping timeout: 248 seconds]
rohitksingh has joined #m-labs
<whitequark>
ugh. I really went over my head and overdesigned the python call translation here...
<whitequark>
ok. I did a thing but it doesn't give LLVM enough visibility.
<whitequark>
I think I know how I need to design this and I'll do that tomorrow.