<DocScrutinizer05>
TZ is not helping user to install a secure system for themselves. TZ is designed to protect the system from user, so when user also is "owner" of of the trusted environment, the whole TZ is pointless and could get implemented in simpler more established and mature ways
<DocScrutinizer05>
or, to re-qiote with emphasis added: >>...The purpose of this framework is: ... to make sure that the platform meets the requirements set BY THIRD PARTY SOFTWARE...<<
Textmode has quit [Quit: "It was one dev, naked in a room with a carton of cigarettes, a thermos full of coffee and bourbon, and all his summoned angels."]
<DocScrutinizer05>
IOW make sure that the 3rd party software doesn't face a system that got "tampered" by user
<DocScrutinizer05>
to put it straight: your 3rd party MP3-player is running in secure environment so the content provider can be sure you have no means to redirect the decoded audio stream to any other destination than the DAC and 3.5mm headset output
<DocScrutinizer05>
since *all* processes running on your system got approved and signed by 3rd party. So you got no tool to do such redirect of audio data. When you're the owner of the "3rd party" signature key then what's the purpose of whole trustzone?
<DocScrutinizer05>
you cannot protect the system from yourself
<whitequark>
it has the same function as separating root and nonroot
<DocScrutinizer05>
yes, exactly. And since we already have such separation in all decent OS, why do we need TZ?
<whitequark>
because if you have regular user on linux, getting root is *trivial*
<DocScrutinizer05>
aha
<whitequark>
local privilege escalation bugs on linux count in hundreds
<DocScrutinizer05>
bugs in TZ count in the zillions
<whitequark>
link?
<whitequark>
I don't disagree, just haven't seen them so far
<DocScrutinizer05>
google for Nokia harmattan aegis
<DocScrutinizer05>
TZ by no means is any intrinsically more safe than calssical root/user separation and privilege management. Just way more complex, and with added benefit that you could deprive user from becoming root *ever* on own device
<whitequark>
you already have that issue
<whitequark>
I mean, on modern smartphones *without* TZ you can commonly only become root via bugs
<whitequark>
and you know what? if a "jailbreak" app can become root, it means that any malware whatsoever can become root too
<DocScrutinizer05>
they have other implementations of same concept
<whitequark>
this is why iPhone security works, and Android is a shithole
<whitequark>
one of reasons, at least
<whitequark>
DocScrutinizer05: no, I mean, even if you only implement this in software, you have the same situation
<DocScrutinizer05>
toldya
<DocScrutinizer05>
TZ is cruft
<whitequark>
still not convinced
<whitequark>
TZ is basically cut down virtualization
<whitequark>
whatever runs in TZ is a "hypervisor", the rest is a "guest"
<DocScrutinizer05>
yes
<whitequark>
virtualization-based sandboxes have a much better track record than OS-based
<whitequark>
Xen has had around fifty advisories through its entire life, only maybe five of them can give you root
<DocScrutinizer05>
and unlike usual virtualization you can run TZ without ever sharing the secret key needed to sign stuff
<whitequark>
this is not a problem of TZ. this is a problem of shitty vendors.
<DocScrutinizer05>
and that'S the ONLY difference between TZ and a usual system
<whitequark>
between TZ and system with virtualization? yes
<whitequark>
between TZ and system without virtualization? no
<DocScrutinizer05>
as soon as you hand out the TZ root secret key, there's no difference to any other supervisor slution of which there are 5 dozen out there
<whitequark>
that I agree
<DocScrutinizer05>
just that TZ is incredibly complex and cumbversome to maintain
<whitequark>
hm, I've talked with someone developing for TZ and they were ok with it
<whitequark>
but I don't know for sure
<DocScrutinizer05>
sure, it's ok for you when you're the "3rd party" that actually owns the key, or you are simply not bothering about who's administrating the target platform and you just get your app you developed to owner of TZ root key for signing it
<DocScrutinizer05>
the point is that *all* your system, from bootloader to last cheesy app, needs to get signed by TZ root key
<DocScrutinizer05>
and you need a list of privileges allowed for every app, that gets part of such signature
<whitequark>
huh? I don't think so, you don't need to sign untrusted code
<whitequark>
it's basically the point
<DocScrutinizer05>
this is how nokia decides what you may or may not run on your N9
<whitequark>
sure, you could use TZ in such fashion if you really want, but nothing in TZ inherently requires it
<DocScrutinizer05>
but that's the *only* purpose of TZ
<DocScrutinizer05>
every app developer needs his app to get signed at Nokia, or it won't run on any N9
<DocScrutinizer05>
if you hand the key out to everybody, you could as well stop using TZ at all, to start with
<DocScrutinizer05>
handing an individual key to every single N9 owner would not differ from simply giving them the root password and not using TZ at all
<DocScrutinizer05>
having one common publicly known key is absolute nonsense
<DocScrutinizer05>
whole trustzone is only for *one* purpose: to allow vendor to have total control over the devices they sell
<DocScrutinizer05>
it really has no other purpose or benefit
jluis has quit [Remote host closed the connection]
<whitequark>
as far as I see TZ is merely a hardware-assisted virtualization feature
<wpwrak>
larsc: it is not targeted against ze user. all i do is make sure ze rockets go up. where ze come down is not my problem ;-)
<ysionneau>
13:38 < whitequark> this is why iPhone security works, and Android is a shithole < why is iPhone any better?
<whitequark>
ysionneau: it's generally pretty hard to jailbreak an iPhone
<whitequark>
(it doesn't matter to this discussion whether this is achieved via good coding practices, virtualization, TZ, whatever.)
<ysionneau>
isn't it the same principle? you get root through security bug
<whitequark>
if you can't do it, then malware can't do it as well
<whitequark>
sure. but jailbreaking android devices is trivial
<ysionneau>
I honestly don't know iPhone world
<whitequark>
this means you can't rely on its sandboxing at all.
<ysionneau>
haven't all iPhones been rooted?
<whitequark>
most jailbreaks require explicit physical user action, like tethering it to a PC and uploading something
<ysionneau>
maybe with a few months lag at each new iOS release
<ysionneau>
oh ok
<ysionneau>
I didn't know that
<whitequark>
since I think iOS 4 or something?
<ysionneau>
so no kernel exploit or something
<ysionneau>
well, not exploitable from app
<whitequark>
actually, not quite, you usually need multiple exploits
<whitequark>
but the days of jailbreaks from inside the device are gone
<whitequark>
and this is good
<ysionneau>
indeed Android has and had tons of vuln accessible from low privilege app
<ysionneau>
how do they achieve that?
<ysionneau>
very low system call attack surface,
<ysionneau>
?
<whitequark>
well, for example, you can't mark data pages as executable
<whitequark>
so no JITs, but also less exploits
<whitequark>
then they have ASLR
<whitequark>
kernel ASLR, too
<ysionneau>
modern Android have ASLR pretty much everywhere I think
<whitequark>
yes, and then 80% of vendors put some shitty library with ASLR disabled
<wpwrak>
well, maybe that will make people realize they don't need FTDI chips. they've been a bad choice for a long while already and it seems it just got a little worse
<whitequark>
overpriced
<wpwrak>
and very badly documented
<wpwrak>
i once tried to use one of their chip to make an in-circuit programmer. failed miserably because i couldn't toggle pins reliably. never found out whether it was just a documentation issue or a silicon limitation. lesson learned: use an USB MCU and accept that you need something already existing to bootstrap it.
<wpwrak>
so with ftid you're basically screwed if you leave the well-traveled path. and they also did a number of stunts like undocumented EEPROM content that took forever to reverse-engineer.
<larsc>
wpwrak: that kernel patch was a reply to the FTDI diver changes
<wpwrak>
so it's quite ironic that their chips are so popular in the free and open hardware development scene. these are not our friends.
<wpwrak>
larsc: ah, so it was meant to be a joke. and indeed, it does seem to actively alter the Vendor ID.
<rjeffries>
wpwrak I did not take time to look at price of that dongle, but assume it is low cost. I am a poor judge of open-ness but it seems they are trying to have an open hardware platform.
<rjeffries>
a mumble about security and the password morass: anelok seems to be promising as best I can tell. I wonder if the following use case is supported: using anelok strictly as a secure password vault. That's how I use the (open) Android program Universal Password Manager (UPM). Yes, I then type in a password manually, and yes that fact influences my password construction a bit.
<rjeffries>
So the question I have is if a user wants a small relatively secure password vault and accepts they will look up passwords and type them in, how well will anelok support that workflow? It assumes a simple easy fast seach to find teh desired entry.
<rjeffries>
thx
tumdedum has quit [Ping timeout: 250 seconds]
tumdedum has joined #qi-hardware
<DocScrutinizer05>
larsc: nobody needs to use TZ cruft. And actually TZ comes with a side effect of usually no access to the secured conzent via booting a rescueOS or by flashing a new kernel. Usually those HS devices (TZ-enabled) only allow flashing new stuff after _complete_ erasute, which is absolutely fine for stuff like crypto containers
<DocScrutinizer05>
erasure*
<DocScrutinizer05>
not like a 89c1051 couldn't do same ;-)
freespace has quit [Ping timeout: 258 seconds]
freespace has joined #qi-hardware
* DocScrutinizer05
idly wonders who's "inverse path" and what they actually do
<wpwrak>
nicksydney: cern are doing good work. what i don't like so much is that kicad is breaking the old "user experience". also, the newer versions are much slower than the older ones
<nicksydney>
wpwrak: is it because they are relying too much on GPU processing ?
<nicksydney>
to make the rendering faster ?
<whitequark>
GPU is certainly the way to go
<wpwrak>
yes, and the GPU-based part doesn't seem to be very usable for manual routing. so for that one has to use the old interface, which is now very slow
<wpwrak>
whitequark: dunno. it's not as if the drawing operations would be complex. and doing the same work used to be much faster in the past. on the same hardware.
<wpwrak>
i think it's mainly C++ bloat
<whitequark>
wpwrak: sure it's not your graphic drivers?
<whitequark>
(integrated intel should be perfect for this kind of stuff, not sure what you use though)
<wpwrak>
my pc from an earlier generation. has radeon and nvidia.
<whitequark>
ah, so nv.
<nicksydney>
wpwrak: that's the same issue i had previously when using the master branch