lobito has quit [Read error: Connection reset by peer]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
drrz has quit [Read error: No route to host]
pagurus has joined #neo900
pagurus` has quit [Ping timeout: 276 seconds]
herpderphurr has quit [Ping timeout: 255 seconds]
freemangordon has joined #neo900
lobito has joined #neo900
drrz has joined #neo900
drrz has quit [Read error: No route to host]
drrz has joined #neo900
drrz has quit [Read error: No route to host]
freemangordon has quit [Ping timeout: 244 seconds]
chomwitt has quit [Ping timeout: 240 seconds]
chomwitt has joined #neo900
chomwitt has quit [Ping timeout: 244 seconds]
paulk-nyan-big has joined #neo900
herpderphurr has joined #neo900
SylvieLorxu has joined #neo900
paulk-nyan-big has quit [Quit: Leaving]
jefrite has quit [Ping timeout: 244 seconds]
jefrite has joined #neo900
paulk-collins has joined #neo900
xman has joined #neo900
N912 has joined #neo900
<N912>
Sooo...is the q3 2016 shipping date still realistic?
<DocScrutinizer05>
no way
<DocScrutinizer05>
sorry
<N912>
Aw...sad
<DocScrutinizer05>
it was q4 at beginning of the year
<N912>
So it's, some
<DocScrutinizer05>
now we have to switch our complete toolchain and find a new layouter (both accomplished now), which caused severe delays
<N912>
Oh well, so there is no point in giving out another eta, I guess?
<DocScrutinizer05>
not really at this moment
<DocScrutinizer05>
very sorry about that, it's quite embarrassing
<DocScrutinizer05>
in january we heard that our layouter Nikolaus announced a 6 to 9 months non-availability. So we were paralized between "could we be faster when we find a new layouter and toolchain ruight away" and "what if we do that switch now and then we find no layouter and Nikolaus refuses to use the new toolchain in 6 months?"
<DocScrutinizer05>
finally a 2 months ago we learned Nikolaus isn't available anymore for layout any time soon, at all. So we finally were unblocked to the worse side, but unblocked at least, and now we accomplished the switch to kicad and we found Ahycka who says she is willing to do the layout and she got professional experience
<N912>
I see, so in the end, anything you could've done, would've created a delay. What a pity.
<DocScrutinizer05>
yes
<N912>
Oh that sound good!
<DocScrutinizer05>
very sorry about that, and very embarrassed
<N912>
People it's professional experience are hard to find for a project like this, I guess.
<DocScrutinizer05>
on the bright side we are way more open now, using FOSS EDA tool kicad
<N912>
No need to apologize.
<DocScrutinizer05>
yes, very hard to find
<N912>
I'm sure that you're doing your best. This is really a quite complicated and advanced project and, in my opinion, it's impressive how far you guys have come so far. :)
<N912>
So it's theoretically 100+ complete neo900 devices?
<DocScrutinizer05>
~40 + 24 + 50 + 30
<infobot>
144
<DocScrutinizer05>
yes
<N912>
Nice. Do you know how many devices/boards have been preordered already?
<DocScrutinizer05>
+1EURFunding top up-9439
<DocScrutinizer05>
Neo900PARTIAL FUNDING towards Neo900 complete device-223
<DocScrutinizer05>
NeoNPARTIAL FUNDING towards NeoN bare board-112
<DocScrutinizer05>
forget the minus signs, they are because our stock in shop is zero for all
<DocScrutinizer05>
actually from a shop perspective the numbers are "Available quantity for sale"
<DocScrutinizer05>
so since stock is zero, this is stock - orders = -orders
<N912>
So you still need to source a few N900s for the complete devices. What if you can't find enough (that are in an acceptable condition)
<N912>
Makes sense! :p
<DocScrutinizer05>
we just received another 40 yesterday, see above. And that's a process that's ongoing
<N912>
I see. Well, you stil got enough time life
<N912>
Left to source the remaining devices
<N912>
I gotta go for now. Thank you, for taking time for informing me, Doc. :)
* N912
will be back
N912 has quit [Quit: N912]
<DocScrutinizer05>
o/
herpderphurr has quit [Ping timeout: 255 seconds]
* Wizzup
has about 10 n900s at home if you really cannot find them
<Wizzup>
but I see lots of them on local markets every day
<Wizzup>
for 30-50 eur
<Wizzup>
but I guess you keep them to a higher standard
<Wizzup>
DocScrutinizer05: any news on those beaglebone xM's?
<DocScrutinizer51>
we're getting a 5 more soon
drrz has joined #neo900
<Wizzup>
beaglebone's?
Pali has joined #neo900
<DocScrutinizer05>
BB-xM
freemangordon has joined #neo900
<DocScrutinizer05>
phonecall "Hello Mr Resienweber, here is your friendly slave dealer. Would you be available for a job as technical project lead in Austria, which would perfectly meet your profile?"
<atk>
M3 without vPro (no AMT) and M3 with vPro (AMT)
<atk>
I feel that vPro would literally defeat the purpose though, so I'm not sure why they offer it.
<atk>
(vPro is an umbrella term for among other things, AMT)
<atk>
This seems like a good device for storing keys.
<atk>
Hmm, they seem to say that x86 and OOTB windows support is the only way. I don't know, I feel that all the use cases for this machine don't require either Windows or x86... but whatever
qws-user-1228 has joined #neo900
louisdk has quit [Ping timeout: 265 seconds]
<DocScrutinizer05>
I don't think they say "it's the only way" - all the opposite they seem to not care what OS you're running on that hardware
<DocScrutinizer05>
s/all the opposite/quite the contrary/
qws-user-1228 has joined #neo900
<DocScrutinizer05>
>>ORWL meets all the minimum and recommended system requirements for running Qubes OS, including a processor that supports VT-x and VT-d. We offer Qubes OS as one of the pre-installed operating system options.<<
<atk>
DocScrutinizer05: read the section about X86
<atk>
they say that support for windows is not optional
<DocScrutinizer05>
so what?
<atk>
And they say that there's no alternative to x86
<DocScrutinizer05>
again, so what?
<atk>
They're also saying that as a result ME is a necessary evil.
<DocScrutinizer05>
ME?
<atk>
I am saying that this reasoning seems flawed and that x86 does indeed not seem to be the only option.
<atk>
Intel ME from intel AMT
<atk>
proprietary black box of tricks
<atk>
mandatory and inseperable
<atk>
inseparable*
<DocScrutinizer05>
[2016-08-31 Wed 21:58:46] <atk> M3 without vPro (no AMT) and M3 with vPro (AMT)
<atk>
also, microcode
<atk>
Yeah, that's what vPro seems to mean indeed, but for some reason their own documentation seems to suggest otherwise.
<DocScrutinizer05>
also incorrect, the second one is M7
<atk>
It's possible the M3 includes AMT without being classified as vPro
<atk>
yes, I mistyped obviously
<DocScrutinizer05>
honestly, I'm not interested in discussing this
<DocScrutinizer05>
I'm pretty sure *they* did (and do), in their media channels whatever they are
<atk>
That's fine, I didn't mean for you to discuss it, I was just throwing information out there.
<DocScrutinizer05>
(([2016-08-31 Wed 22:42:34] <atk> It's possible the M3 includes AMT without being classified as vPro)) this is a red herring since same rationale applies to *all* chips
<atk>
All what chips? vPro is a marketing term, all vPro intel CPUs have AMT, I don't know if all intel CPUs with AMT are classified as vPro
<atk>
but the other inherently insecure thing about all x86 is microcode
<DocScrutinizer05>
so what?
<atk>
It's possible that's the logic behind their x86 section (talking about the issues of x86 in terms of microcode and then mentioning AMT at the end)
<atk>
The point is, x86 does not seem to be a particularly good candidate for a secure device like that, and they're saying that x86 is the only arch which will be useful to their target audience, and I disagree, I think ARM based would be just as useful, but maybe I don't know something they do about the purposes of such a device.
<DocScrutinizer05>
this devoce provides a FIPS 140-2 class-4 tanper-proof hardware. It's pretty much out of scope what are the potential security flaws in a particular SoC or architecture, as long as they are known and means to cope wwith them exist. And there must be, otherwise the device wouldn't stand a chance to even gain class-2 cert
<atk>
I have no idea what this certification involves, or if they have a subclause saying "we trust intel" but intel microcode updates are proprietary, potentially damaging to security and mandatory
<atk>
It's code which runs on the CPU which you have no control over or no ability to audit. Maybe these cert people get special access to the microcode, I don't know.
<DocScrutinizer05>
please read about the *purpose* of the whole project then
<DocScrutinizer05>
this is no router or firewall hardware
<atk>
The purpose seems to be to produce a hardware secure device with certification which is also open source and penetration tested but no amount of physical security solves potential software threats.
<DocScrutinizer05>
this is a device that's hardened against any physical tampering
<atk>
Indeed, it's great at that.
<atk>
It's brilliant on that front.
<DocScrutinizer05>
it's neither meant to protect users from exploits targeted against a browser, nor against exploits targeted against any SMM
<atk>
SMM?
<DocScrutinizer05>
for both there are other means to protect the device
<atk>
Right, but there are no protections against malicious microcode and (with the M7 AMT), at all.
<atk>
Apart from never connecting the device to a network.
<DocScrutinizer05>
ME
<DocScrutinizer05>
sorry, that's nonsense
<DocScrutinizer05>
for that you use firewalls and evaluated&certified updates
<atk>
Please explain how you protect against your CPU running _proprietary_, _mandatory_, _closed_, _un audited_, code.
ravelo has quit [Ping timeout: 264 seconds]
<DocScrutinizer05>
and again, those attack vectors potentially exist in *all* architectures
<atk>
(microcode)
<atk>
no they don't
<atk>
they don't exist in ARM because ARM does not have microcode
<atk>
it's a feature of x86
<atk>
with ARM any potential attacks would have to be on the CPU die itself.
<DocScrutinizer05>
haha, please prove that ARM doesn't have microcode
<DocScrutinizer05>
or any other silicon level backdoor
<DocScrutinizer05>
or a flaw in ROMBOOT
<atk>
Yes, but these kind of silicon level backdoors or pre-existing microcode are nowhere near as bad as mandatory microcode updates.
<DocScrutinizer05>
agaion, that's not relevant here
<atk>
there's only so much that these manufacturers can predict about the execution of a CPU in order to successfully leak some kind of information
<DocScrutinizer05>
in security you don't care _how_ bad some threat is
<DocScrutinizer05>
you _always_ act as if the threat is *real*
<atk>
No, you act based on which kinds of threats you want to repel.
<DocScrutinizer05>
ok, whatever. Sorr<y for going off topic
<DocScrutinizer05>
I shouldn't havve mentioned it in here
<atk>
It is many times easier for a malicious entity to produce through intel microcode which can inject some sort of malware or produce some sort of information leak than it is for an architecture where these things can't be updated to predict what code someoene might be running in 5 years from now and predict how to A: detect the correct conditions for injection / leaking B: perform the leak without disruption C:
<atk>
hide it all
<DocScrutinizer05>
ok, whatever. Sorry for going off topic. I shouldn't have mentioned it in here
<atk>
We can move it to a query because I'd be interested in discussing it further.
<DocScrutinizer05>
I'm not
<DocScrutinizer05>
I'm aware how security works. But I'm also aware of the discrepancy between what this ORWL device is meant to be and what you expect it to be
<atk>
Well, it that is rather unfortunate, I greatly enjoy discussions on the topic of hardware security issues.
<DocScrutinizer05>
this particular discussion is pointless
<atk>
I think this project does not strike a particularly even approach at securing all fronts to the same level, that's my issue with it, that's all I'm trying to say. I don't think this is pointless.
<DocScrutinizer05>
their product requirements (which they decided on based on criteria you don't know) demand "x86 compatibility", and there's no point in discussing how hard it is to operate a device with that architecture in a secure way. When you're afraid you see attack by malicious microcode, then don't allow microcode update. When you expect attacks to Management Engine, don't connect to internet at all, or use appropriate firewalling means
<atk>
They could be more clear on the criteria.
<DocScrutinizer05>
btw note that the device seems to not even have an ethernet connector
<DocScrutinizer05>
go figure!
<DocScrutinizer05>
and there's NO WAY to protect hardware from idiot users running rogue software on it
<atk>
I am not trying to say that there is.
<DocScrutinizer05>
(incl microcode updates)
<atk>
microcode updates are sometimes mandatory.
<DocScrutinizer05>
aha
<atk>
when the CPU is unstable without them
<atk>
a side effect of the complexity of x86
<DocScrutinizer05>
then the device is broken and you can send it in for repair or money-back. simple as that
<atk>
intel wouldn't call it broken, intel would tell you to shut up and install the updates
<DocScrutinizer05>
who gives a fuck about intel. Really could we stop this discussion now, please?
<atk>
You talked that you wanted to stop it but then you added more to it. Yes we can stop it but please don't add more to it if you don't expect me to respond.
<DocScrutinizer05>
yw to read chanlogs to check your assertion
<atk>
Which assertion?
<DocScrutinizer05>
the assertion that I added new info after you stopped talking about it
<atk>
I agreed to stop the discussion when I said "We can move it to a query because I'd be interested in discussing it further." you continued it when you said "But I'm also aware of the discrepancy between what this ORWL device is meant to be and what you expect it to be" this implies that I am wrong because I do not understand the purpose of the device which reopened the discussion.
<DocScrutinizer05>
well, sorry when I refuse to discuss my estimation on your understanding about the threat vectors a device with 2 USB (one for power) and one HDMI port is meant to deal with
<DocScrutinizer05>
the hardware design is clearly tailored towards a usage scenario that doesn't even expose the attack surfaces you elaborated on
<DocScrutinizer05>
so also please excuse when I find a jerk reaction bashing of "Intel chips inside" a little annoying
<atk>
Please, you are once again discarding the issues with x86 as non-issues. To further the aforementioned point: Intel will tell you to install the updates and there's nothing stopping the people making the device from doing the same. x86 microcode is a problem. The page does not discuss why x86 is so important other than asserting that it is. There is no information on why they think x86 is so important for
<atk>
this device. The fact that the device has Wi-Fi opens cpu microcode to the possibility of (and this would be quite difficult) leaking information.
<DocScrutinizer05>
smells like FSF
<atk>
intel is not some kind of saints, they have a business model and a purpose, I don't think it fits in with this style of device
<DocScrutinizer05>
"a chip is a good chip as long as we don't _know_ it runs firmware"
<atk>
This is not what I am saying.
<atk>
The specific point is about microcode updates which may be mandatory.
<DocScrutinizer05>
please see what we explained about no firmware ever can get trusted. But also note that a rogue firmware is pointless as long as there's no way it could actually *do* something rogue
<DocScrutinizer05>
no microcode update ever is 'mandatory'
<atk>
It might be mandatory if the device is unstable without it.
<DocScrutinizer05>
unless the device didn't work within parameters at the time of shipping
<DocScrutinizer05>
in that case the device is defect
<atk>
Correct, and to continue this point, nothing stops the people making the device from telling you that they did nothing wrong and that you must update the microcode.
<DocScrutinizer05>
if the cpu had no microcode, the instability would be 'in hardware', so where's the difference?
<atk>
If they have a clause saying that this is in fact a valid reason to return it, point it out and I'll retract my statement.
<atk>
The instabilities are caused by the complexities and intricacies of x86
<atk>
Nothing stops the people making the device from saying: "well you bought x86, this is an expected thing, install the microcode updates"
<DocScrutinizer05>
yeah, and nothing stops them from telling you you can get lost when you didn't notice any problems during the 2 years you already owned the device, and now you want to start bitching at them because their microcode update they provide to fix a problem you never encountered is not compliant with your intended usecase of the device
<DocScrutinizer05>
instabilities doen't grow on silicon lawn, they are either there from beginning or will never show up
<atk>
It might be that compilers change to use features of the CPU that were previously not used and this inadvertently highlights some instabilities.
<DocScrutinizer05>
then don't use that new compiler!!!
<atk>
And this doesn't address the point that you will not be doing this 2 years after purchase
<atk>
I think there's nothing stopping them from saying no to a request to return the device if it came "faulty"
<atk>
since it's an expected side effect of x86
<atk>
Possibly the issue is subtle and you only DO notice it two years later.
<DocScrutinizer05>
I still think this whiole discussion is a pointless "THEY *could* do evil LATER"
<atk>
Maybe a specific multiplication calculation which happens once every two years triggers it. Who knows.
<DocScrutinizer05>
extremely annoying
<DocScrutinizer05>
and again, what would you do if there was no microcode update?
<atk>
Yes, but this whole device is aimed at people who hypothetically might be under some massive hypothetical threat of physical attack, what stops whoever is the attacker (government, who knows) from instead of going for the physical attack, going for the software attack
<DocScrutinizer05>
you couldn't send in the device for repair a 2 years later anyway
<atk>
if there was no microcode update, you would expect a refund
<DocScrutinizer05>
hahaha
<atk>
they could say: "well there's a fix so you can't return it"
<DocScrutinizer05>
one morre "they could" and I'm out!
<atk>
This whole device is based around some hypothetical massive physical threat
<atk>
It's engineered to perfection to prevent arbitrary hypothetical attempts by some professional to breach it.
<DocScrutinizer05>
FFS the device is a huge dongle!!!
<DocScrutinizer05>
NOT a internet PC
<atk>
They're asking for certification for the device. It's obviously aimed at someone who seems to be some government spy or diplomat or snowden.
<atk>
It has Wi-Fi
<DocScrutinizer05>
stop this now!
<sicelo>
which device are you talking about? Neo900? or something else?
<DocScrutinizer05>
ORWL
<DocScrutinizer05>
sicelo: I talked with the guy building it for an hour at CCCamp15
<DocScrutinizer05>
we discussed how secure the device was and what might be the threat vectors
<DocScrutinizer05>
very nice and competent guy
<DocScrutinizer05>
sicelo: ORWL is a portable mini PC that's class-4 tamper proof when you lose it
<DocScrutinizer05>
means not even FBI could force the manufacturers to unlock it for them. Nor will they find anybody else would could guarantee they could
<DocScrutinizer05>
when the device is locked, there is no way at all to unlock it
<DocScrutinizer05>
except when you know the credentials and own the keyring
<DocScrutinizer05>
even when the device is kept powered, removing the keyring "fob" from BLE range will lock the device