<w3bspl0it>
boot loader is signed and verfies kernel
<w3bspl0it>
need to disable secure boot
<w3bspl0it>
i had some thoughts
<w3bspl0it>
access boot loader in memory but UART is disabled for that
<w3bspl0it>
all interrupts are disabled
<w3bspl0it>
possible to boot from sd card but verfication still in place
<wpwrak>
that's ... on the ben ?
<w3bspl0it>
streaming player
<wpwrak>
then i suppose how you design your "secure boot" would depend on what sort of hardware that player has ...
<w3bspl0it>
Roku 3 streaming player
arielenter has joined #qi-hardware
arielenter has quit [Quit: Leaving.]
dos1 has quit [Ping timeout: 252 seconds]
atommann has joined #qi-hardware
arielenter has joined #qi-hardware
arielenter has quit [Read error: Connection timed out]
unclouded has joined #qi-hardware
xiangfu has joined #qi-hardware
arielenter has joined #qi-hardware
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #qi-hardware
arielenter has quit [Read error: Connection timed out]
arielenter has joined #qi-hardware
arielenter has quit [Quit: Leaving.]
arielenter has joined #qi-hardware
w3bspl0it has quit []
wolfspraul has joined #qi-hardware
jekhor has joined #qi-hardware
arielenter has quit [Read error: Connection timed out]
michael_lee has joined #qi-hardware
michael_lee has quit [Remote host closed the connection]
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #qi-hardware
Luke-Jr has quit [Remote host closed the connection]
Luke-Jr has joined #qi-hardware
arielenter has joined #qi-hardware
Luke-Jr has quit [Read error: Connection reset by peer]
arielenter has quit [Client Quit]
Luke-Jr has joined #qi-hardware
jekhor_ has joined #qi-hardware
jekhor has quit [Ping timeout: 240 seconds]
jekhor_ has quit [Read error: Connection reset by peer]
jekhor_ has joined #qi-hardware
gbraad_ has joined #qi-hardware
gbraad_ has joined #qi-hardware
gbraad has quit [Ping timeout: 246 seconds]
jekhor_ has quit [Read error: Connection reset by peer]
jekhor has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
atommann has quit [Ping timeout: 276 seconds]
sb0 has joined #qi-hardware
atommann has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
jekhor has quit [Read error: Connection reset by peer]
jekhor has joined #qi-hardware
wolfspraul has quit [Ping timeout: 240 seconds]
wolfspraul has joined #qi-hardware
snufkintardis has joined #qi-hardware
snufkintardis has quit [Ping timeout: 240 seconds]
atommann has quit [Quit: Leaving]
wolfspra1l has joined #qi-hardware
wolfspraul has quit [Ping timeout: 240 seconds]
xiangfu has quit [Ping timeout: 245 seconds]
<DocScrutinizer05>
OUCH! tivoization or what?
<DocScrutinizer05>
you want to "root" a tivoized device? forget it, probably simply not worth it, even IF possible
<whitequark>
ehh, plenty of cases where the vendor is a complete idiot
<whitequark>
e.g. galaxy s ii
<whitequark>
the "secure boot" key is zeroed :D
<whitequark>
and there's some code which indicates that they never actually bothered to turn off "development mode" in production
<DocScrutinizer05>
secure boot is da shite, usually the core developers don't bother or even hate it. It's a management decision that makes implementation of tivoization a product requirement
<DocScrutinizer05>
a quote from infobot about ~'#maemo aegis':
<wpwrak>
"secure boot" has valid purposes. but you rarely see it used for them.
<DocScrutinizer05>
the "valid purposes" are pretty hard to implement and deploy, without producing negative impact on user's freedom
<wpwrak>
of course, why make the effort to make something better for the customer if it's so much more fun to just be an asshole ? :)
<wpwrak>
well, sometimes the priority isn't freedom but security. e.g., think of a password safe. you _want_ it to be hard to mess with its internals.
<DocScrutinizer05>
Nokia claimed aegis was "for the user's security", in fact it been one huge PITA
<DocScrutinizer05>
you can't protect your password vault by any other means than forbidding installation of any software that's not certified by a central authority
<wpwrak>
well, i plan to give anelok a bit more flexibility. i want to leave it to the user to install certificates, or to revoke them. that would include the certificate they use to install certificates.
<DocScrutinizer05>
then you need to ship the device with this TPM infra already set up and engaged, and you need to deploy the root cert private key in a separate channel to user
<DocScrutinizer05>
and of course each root cert needs to be unique
<DocScrutinizer05>
otherwise rogue-user is using the privkey you send to him, to compromise/root devices you send to other customers
<DocScrutinizer05>
then each user basically needs a tool to sign installation packages in a trusted environment with his unique private key
<DocScrutinizer05>
dunno what's your benchmark for "trusted environment" in the latter, maybe a standard PC would satisfy your security requirements
<DocScrutinizer05>
anyway you must be sure about that environment not compromising your private key or the packages you sign
<DocScrutinizer05>
and obviously you don't want to install the privkey to anelok, no matter how trusted you consider this environment. So on-platform signing is a nogo
<DocScrutinizer05>
at this point you should stand back a step or two, look at the whole picture and ask "what's the purpose of this exercise?"
<DocScrutinizer05>
avoid rogue software getting installed on your secure device aka anelok? can as well egt implemented with proper usual unix/posix permissions/capabilities
<DocScrutinizer05>
no root password, no installation of rogue software
<DocScrutinizer05>
nota bene to avoid flashing a new kernel by rogue hax0r you don't need any of that cert and TPM/tivoization crap. You just need to make sure the flashing is asking for a unique password assigned to your particular device
<DocScrutinizer05>
IOW as long as yur ROM bootloader has a feature to flash new kernel but doesn't allow readout of the kernel on device, it's absolutely sufficient when you hardcode your individual unlock key for the TPM storage to your kernel before flashing it
<DocScrutinizer05>
of course it's even better when your lowest stage bootloader (aka ROMBL) already asks for a password to allow anything to run on the device, during boot
<wpwrak>
(separate channel) correct. each user needs to get a "personal" master certificate. plus is encouraged to change it, so that not even the issuer has a way of knowing.
<DocScrutinizer05>
this way nobody who doesn't know your password could install any software at all to the device. Still no PKI and certs and stuff needed
<wpwrak>
(environment) anelok can still generate private keys. that's not insecure because what those keys are protecting is anelok itself. so if it's already compromised, you don't make things worse.
<DocScrutinizer05>
but also not better
<wpwrak>
better than "safe" ? :)
<DocScrutinizer05>
better than "already compromised"
<wpwrak>
well yes, but if it's gone, it's gone.
<wpwrak>
you can't put the genie back in the bottle
<DocScrutinizer05>
exactly, the whole thing is a bloated monster to establish... snakeoil, usually. Or tivoization which means you assign root to somebody else (manuf) and you don't own your own device anymore
<wpwrak>
the latter is not the idea. you get all the keys you want. the device may or may not come with "immutable" flash. (would be a nice order-time option)
<wpwrak>
if "immutable", you can't even blank it. if "mutable", you (or anyone else) can.
<DocScrutinizer05>
sure somebody could run your original kernel in a virtual machine, on anelok, thus tricking you into thinking the device is still "clean". But could they *really* or is this just a theoretical attack vector that doesn't fit through the eye of the needle of your actual hardware resources?
<wpwrak>
blanking means that all keys are deleted. so the device can't access things it has access to before blanking. but of course you could then install any malicious firmware you want.
<wpwrak>
kernel ? anelok doesn't run linux. it's just a lowly cortex M0+
<DocScrutinizer05>
doesn't matter
<DocScrutinizer05>
call it kernel or call it main()
<DocScrutinizer05>
I don't see how cert PKI helps in all this
<wpwrak>
i'm not talking about the global scheme, with verisign, thawte, cacert, turktrust, and all these. that's obviously pointless.
DocAvalanche has joined #qi-hardware
DocAvalanche is now known as DocScrutinizer51
<DocScrutinizer05>
grrrrr, ZNC acting up
<wpwrak>
i'm not talking about the global scheme, with verisign, thawte, cacert, turktrust, and all these. that's obviously pointless.
<wpwrak>
the issuer would be anelok.com. then you're free to do what you want.
<DocScrutinizer05>
me neither does
<wpwrak>
anyway, gotta run. dentist's appintment.
<DocScrutinizer05>
eeew
<DocScrutinizer05>
(ZNC) hmm
<DocScrutinizer05>
roh: did you boot andromeda?
<DocScrutinizer05>
(thus lagrange)
<DocScrutinizer05>
nevermind
kyak has quit [Read error: Operation timed out]
kyak has joined #qi-hardware
pcercuei has joined #qi-hardware
jekhor has joined #qi-hardware
Luke-Jr has quit [Excess Flood]
Luke-Jr has joined #qi-hardware
pcercuei has quit [Ping timeout: 240 seconds]
jekhor has quit [Ping timeout: 258 seconds]
arielenter has joined #qi-hardware
jekhor has joined #qi-hardware
<wpwrak>
(eew) naw, dental procedures are pretty tame nowadays. well, if you go to a capable dentist. if you choose one whose principal professional experience is with four-legged patients, you may get what you deserve :)
arielenter has quit [Ping timeout: 276 seconds]
arielenter has joined #qi-hardware
<larsc>
or just compensate their lack of talent with enough NO ;)
<wpwrak>
grrk-bzzt: more like the pyramids. relaxed, majestetic, not worried by what hurries past them, but yes, not dancing and jumping around either.
<grrk-bzzt>
That was a strange explanation
<wpwrak>
thanks ;-)
<larsc>
I'd say it is suspended until further notice
<wpwrak>
and which part of the procedure do you disagree with ?
<eintopf>
:)
<eintopf>
page 126 figure 10-1 desribes "Transactions between AT86RF231 and Microcontroller during Receive"
<eintopf>
First IRQ_2 occures (IRQ_\RX_START)
<eintopf>
which indicates that's an rx interrupt, so I make a spinlock for is_rx or something else
<eintopf>
then waiting for the IRQ3 (IRQ_TRX_END)
<eintopf>
but I can't to that
<wpwrak>
i don't like thw word "spinlock" in this context, but go on ...
<eintopf>
, because the RX_START interrupt occurs after SFD
<eintopf>
wpwrak: yes I know :(
<eintopf>
page 39 describes when IRQ2 (RX_START) occurs
<wpwrak>
(after SFD) correct, even after PHR (page 39, figure on top)
<wpwrak>
yeah :)
<eintopf>
ah, we understand :)
<eintopf>
wpwrak: I don't know if I really need only the TRX_END irq for tx/rx
<eintopf>
because then I need a spinlock is_tx
<eintopf>
because I don't know what I am doing when TRX_END occurs
<wpwrak>
true, there is a race condition
<wpwrak>
what you could do is:
<eintopf>
maybe read the TRX_STATE
<wpwrak>
- if you're in RX mode, any TRX_END means that something has arrived
<eintopf>
yea... and I get the TRX_STATE also when I reading out the IRQ_STATUS
<eintopf>
that's the first receiving byte
<wpwrak>
- if you're in TX mode, first enter PLL_ON and make sure you've arrived there. then check TRX_END. and only then you're really in TX mode.
<wpwrak>
you can set it up to do this, yes. careful, though: the 230 can't do that.
<wpwrak>
only 231/232/233
<eintopf>
... :(
<eintopf>
okay, thanks
<wpwrak>
of course, the 230 has many other interesting problems ;-)
<eintopf>
I tought there would be also some IRQ's for a successful statechange
<eintopf>
but there is nothing...
<eintopf>
wpwrak: but why the hell they describe the receive procedure like this
<eintopf>
it doesn't work for me
<eintopf>
I need to write a mail to atmel
<larsc>
wpwrak: do you know any production ready things that use 6lowpan?
<wpwrak>
i'm not even sure what PLL_ON does if you're in BUSY_RX. it seems that it would wait until the frame ends, then return to RX_ON, and then execute the PLL_ON
<wpwrak>
larsc: hmm no, but then i don't have much of an industry overview
<wpwrak>
(assuming you mean "finished" products, not just components. else there are some adapters, including of course atben/atusb :)
<eintopf>
ah, I need to change the SPI_CMD_MODE for the trx state...
<eintopf>
wpwrak: :/
<larsc>
we may or may not (I can't neither deny or confirm at this point ;)) want to build a demo showing interoptability with 3rd party 6lowpan solutions
<eintopf>
it works with contiki
<eintopf>
point to point
<eintopf>
but not tinyOS, the tinyOS 6lowpan stack isn't rfc complaint
<eintopf>
(I mean the BLIP stack)
<eintopf>
larsc: I run also coap on my linux system
<wpwrak>
that's almost begging to be misunderstood
<eintopf>
wpwrak: the libcoap uses also autoconf defines in API headers
<eintopf>
but I have a workaround for that
<wpwrak>
whitequark: people who complain about C being "dangerous" are just cowards who try to avoid being held responsible for their mistakes :)
<eintopf>
the complete buildsystem is a autoconf without automake :(
<wpwrak>
a first step in the right direction. now just get rid of the rest of autocrap ...
<whitequark>
wpwrak: or the direct opposite? they have a sense of responsibility, and so they don't want to use a tool which amplifies their mistakes by several orders of magnitude
<eintopf>
wpwrak: you don't like autotools?
<whitequark>
I mean, building a house with lead paint is dangerous, and no amount of "don't lick lead paint if you wanna live" is going to convince anyone to change building codes
<whitequark>
even if lead paint is marginally cheaper than modern synthetic ones
<wpwrak>
eintopf: i'd rather depilate my testicles than use that steaming pile of bovine feces ...
<whitequark>
using C in 2014 is building a house painted with lead and lined with asbestos, and replying to the complaints of cancer and developmental delays that "omg, but there is already 1000 houses built like that, and we had a WHOLE BUCKET of lead paint, it's not like you can let that just *rot*."
<eintopf>
wpwrak: ah, I used google translator to understand your sentence
<eintopf>
that's funny :)
<wpwrak>
whitequark: you're still young. there's still plenty of time to learn to appreciate the greatness of C :)
<whitequark>
wpwrak: it's funny, considering that I know C well enough I could write a compiler *shrug*
<eintopf>
wpwrak: it works with the TRX_STATUS in the IRQ_STATUS request
<whitequark>
people seem to have a weird sense of pride in using horrible tools. true, using your homemade chainsaw without eye or hand protection probably raises your self-worth, but it doesn't help those maimed by the parts flying around at subsonic speeds
<wpwrak>
whitequark: i didn't question your proficiency in C but your understanding of its majesty ;-)
<whitequark>
in your own home, you can use whatever you want. the second you publish a new project in C, your fucking fingers need to be chopped off, to prevent damage to those green enough who dared to actually use that
<whitequark>
it's a public safety issue, more or less
<larsc>
na, you just shouldn't use dangerous tools if you are not trained to use them
<wpwrak>
alright alright, now go back, play some 2048, and thank the creator that linux is written in Ada ;-)
<whitequark>
a tool has no need to be majestic. a hammer isn't. I don't even *want* a majestic hammer, regardless of its safety. I want one that drives nails in
<wpwrak>
or .. what was it ... Rubbysh ? :)
<whitequark>
larsc: sure. but there is no consensus on who is considered trained, neither there is any wide understanding of that statement
<whitequark>
so it simply doesn't work in practice
<eintopf>
wpwrak: do you think I can also remove the tx_complete, for wait_for_completion? But I need to control that we don't send something if we already sending something
wolfspra1l has quit [Quit: leaving]
<whitequark>
wpwrak: hence "new projects". it's not realistic to rewrite all of the old C code, not least because you will introduce 9 other bugs for 1 memory safety bug fixed
<wpwrak>
eintopf: isn't the upper layer already taking care of that ? problem is that you can't return before you're done (i think)
<eintopf>
yes
<wpwrak>
eintopf: hence the ###### above would have to be changed, too, if you want to avoid the "no return" restriction
<eintopf>
mhh
<larsc>
I agree that the current situation is very bad and we are kind of heading to the abyss and something has to change
* wpwrak
imagines a mime angrily pounding against an imaginary glass wall. you can see him hammer but you can't hear him scream
<larsc>
but I don't think that switching to "safe" languages will solve things
<larsc>
what we need is formal verification
<larsc>
of every instruction
<whitequark>
that's entirely unrealistic
<whitequark>
safe languages achieve comparatively huge benefit (memory safety) with comparatively little cost
<wpwrak>
and until then, perhaps a bit of a review process. that was the main failing that heartbleed showed.
jekhor has joined #qi-hardware
<whitequark>
wpwrak: that as well. gotofail wouldn't be solved by safe languages.
<wpwrak>
yup. that's another one.
<whitequark>
however, not everything (including stuff directly caused by C's braindead execution model) would be solved by review
<whitequark>
there is *absolutely no reason whatsoever* to leave the sign bit stuff undefined in the standard. there is even less reason to not enable -fwrapv by default in every single compiler that exists. yet, it persists.
<wpwrak>
that cast doesn't look very "top of the foodchain"
<larsc>
the thing is we have tools to catch these kind of errors
<kyak>
code review has to be automated
<kyak>
using tools, right
<wpwrak>
for the rest ... yes, if you change the semantics of something without changing its type, you can get tricky bugs
<whitequark>
larsc: how many C projects are using those tools? 0.0001%?
<kyak>
formal verification is becoming more and more popular in recent years
<sb0>
whitequark, what do you think of lisp machines?
<wpwrak>
e.g., i don't particularly like "int" or its malleability. of course, you could play it safe and use a "struct". yet few people do.
<whitequark>
larsc: it's true we have them today. that wasn't the case a few years ago. the vast majority of people writing C are uneducated and will be uneducated on that matter for decades to come, probably.
<whitequark>
sb0: nothing in particular
<whitequark>
locking the machine to a single execution model dictated by a single language seems a bit silly
<sb0>
can't the same be said of traditional CPUs - made to run C?
<whitequark>
they're not
<larsc>
C is made to run on theses cpus
<larsc>
not vice versa
<whitequark>
I mean, show me evidence they are. the execution model of C isn't even similar to any existing CPU
<wpwrak>
wasn't RISC pretty much in spired by C and friends ?
<whitequark>
wpwrak: the first time I hear that
<whitequark>
sb0: the quirks of C standard very specifically come from the desire to specify the smallest possible subset of operations all interesting CPU support, while remaining backwards-compatible
<wpwrak>
the older designs have ... more complicated histories. and frankly, i can't quite fathom what monster they would have designed the VAX architecture for. maybe Algol 68.
<whitequark>
wpwrak: hm? weren't CISCs designed to be written by hand?
<whitequark>
I mean, compilers didn't change very much since they first appeared, and it was always common knowledge that compiled code uses a tiny fraction of instructions CISCs provide
<wpwrak>
you mean assembler ? well yes, some of them do make it almost look like a high-level language ...
<whitequark>
oh, that may be what you've referred to "inspired by C"
<whitequark>
I would say "designed to be compiled to", yes, I believe that was one of the goals
<larsc>
I always get dizy when I think about that stuff like the whole Linux kernel runs with full privileges
<wpwrak>
(cisc) fond memories of MOVC5 come to mind. memmove (not just memcpy !) and memset, all rolled into one single machine instruction ...
<sb0>
yeah; and it's architecturally very messy. e.g. you can access a USB stick either with fuse + libusb, or with kernel fs + usb mass storage driver
<wpwrak>
and then there's of course POLYH ...
<whitequark>
fuse is horrible.
<whitequark>
nothing that uses fuse ever works reliably.
<whitequark>
eventually, the server dies, and you have processes stuck on IO forever, and you just want to go somewhere and die
<whitequark>
(╯°□°）╯︵ ┻━┻
<sb0>
that's besides the point - and if you "kill" e.g. the ext4 module, bad things will happen too
<whitequark>
but you can't kill the ext4 module.
<whitequark>
and fuse servers will happily go and die themselves. tangentially related, they also often try to provide FS over network.
<whitequark>
FS over network is such a horrible idea it needs to be taught in school right next to Hitler
<sb0>
but the ext4 module can crash... the only reason it doesn't crash often is its code is better debugged than many fuse servers
<wpwrak>
(POLYH computes a polynom of arbitrary degree with 128-bit floating-point numbers. surprisingly, they limited the degree to <= 31. guess someone decided it would be inappropriate for the CPU to spend more than a day on a single instruction ...)
<whitequark>
sb0: well, my point is that in practice, literally no fuse servers I have tried were even remotely usable
<wpwrak>
whitequark: in russian school, they teach hitler
<whitequark>
even when the code technically works well (most of the time) (e.g. sshfs), the leaky abstraction of FS over network makes it a pain to use
<whitequark>
wpwrak: in russia, hitler teaches YOU
<sb0>
but nothing prevents people from writing a fuse server that has the same quality and stability as the ext4 kernel module
<whitequark>
sb0: nothing also prevents people to writing perfect X.509 deserializers on the first try
<whitequark>
somehow that doesn't happen
<wpwrak>
:)
<sb0>
in fact, it should be easier, since debugging userland crashes is easier then debugging kernel crashes
<wpwrak>
and you have valgrind
<whitequark>
I'm not analyzing the reason everything fuse related is shit. I'm stating the fact: it invariably is
<whitequark>
I would be happy for that to not be the case
<wpwrak>
zrafa: you hear him ?
<whitequark>
wpwrak: (valgrind... which is a very complex and expensive way to fix something that only happens because C is dumb)
<sb0>
guess that's because fewer people dare touch kernel modules than fuse - i.e. only people who know how to code to a good extent will even think about writing a kernel module
<kyak>
i'm using sshfs very regularly. Sometimes strange things happen, but not more oftern than with samba for example
<whitequark>
kyak: all network filesystems are broken to various degree
<kyak>
whitequark: so i need to stop using my NAS immediately?? :)
<whitequark>
the model that works is sync of local folders, not direct access to remote by software which can't even detect a disconnect properly or was written without regard to delays
<larsc>
kyak: stop using networks!
<whitequark>
it's... systems design 101. don't pretend that remote things are local. don't replace an interface with another one with a much wider range of failure modes without even adding a way to observe those failures
<larsc>
that would have alsoavoided the heartbleed bug
<kyak>
and also prevent this conversaion from happening
<larsc>
probably the best benefit ;)
<kyak>
whitequark: common, give us something positive today!
<whitequark>
kyak: you're not dead yet
* kyak
hides
<wpwrak>
darn. so this isn't hell yet ?
<kyak>
hell no!
<larsc>
whitequark: he said something positive
<kyak>
positive doesn't arouse much discussion :)
Luke-Jr has quit [Remote host closed the connection]
dandon has quit [Remote host closed the connection]
dos1 has joined #qi-hardware
<wpwrak>
indeed. instant discussion death :)
<wpwrak>
zrafa: btw, did you try to flash over swd ?
arielenter has quit [Quit: Leaving.]
arielenter1 has joined #qi-hardware
zrafa has quit [Ping timeout: 240 seconds]
zrafa has joined #qi-hardware
jekhor has quit [Ping timeout: 252 seconds]
mth has quit [Read error: Connection reset by peer]