-------- Original Message -------- From: Neil Jansen njansen1@gmail.com Apparently from: arm-netbook-bounces@lists.phcomp.co.uk To: Eco-Conscious Computing arm-netbook@lists.phcomp.co.uk Subject: Re: [Arm-netbook] bunnie about riscv Date: Sun, 11 Jun 2017 11:07:56 -0400
Thank you for the information. I have watched a rutkowska video on how complicated intel's management features are. Difficult.
On Sat, Jun 10, 2017 at 11:54 AM, ronwirring@safe-mail.net wrote:
It was very informative. A lot of the technical matter I did not
understand.
This was a GREAT talk. Thanks for the link.
Can you explain: 23.04 The 2 lowermost boxes?
- PDK / Foundries. The factories in which the chips are made in. They're
not open. They're proprietary and there's a implication of trust. 2) Equipment / Raw Materials. The equipment that makes the chips and the raw materials that go into the chips. All a very cloudy and and murky area that is not open, and very proprietary.
He's basically saying that those that want *100%* open source hardware would require infinite recursion down to the raw components, which is impossible. That's the whole point of the talk. The 'impedance mismatch' thing is a sort of metaphor to describe the unrealistic expectations of those idealists that want 100% open source hardware. He's saying it cannot happen today. And BTW I've met Bunnie on several occasions, he's legit, and you can trust what he's saying to be technically correct. He's the real deal.
What is a stepper?
A stepper motor. That is, do you trust the motors that move the machines that made the integrated circuits?
What is fuse?
See this link: https://electronics.stackexchange.com/questions/1262/what-are-atmel-fuses
25.15 The 4 lowermost boxes?
- BIOS
- Firmware
- Hidden / fused silicon blocks - Blocks of silicon on the chip that aren't
usually turned on, but are there. Lots of big vendors are doing this now: Intel, AMD, Nvidia, and it's anyone's guess as to what their real purpose is. That leads to conspiracy theories, as Bunnie said. This is a problem because if you put a chip like this into an open source laptop, it begs the question of what would happen if something turned on that section and started execution code from it? Nobody will know until (A) documentation is leaked from the company or (B) someone reverse engineers it. Basically if you use anything application processor chip made in the last 5-10 years, you probably have some hidden / fused silicon blocks doing god knows what.
- Pre-boot microcode - Microcode (https://en.wikipedia.org/wiki/Microcode)
that executes BEFORE your computer boots. This is a big deal, because everything that happens after this point can be considered suspect. (similar to how a boot virus would spread because it executes first).
- IP industry practices - Intellectual property used by silicon
manufacturers that are not open. What he's saying is, say that you're a silicon vendor and you just bought a intellectual property from ARM to make an ARM chip. They're giving you HDL (hardware description language) and netlists (a large list of the connections to be made in the die), and guess what, they gave them to you encrypted so that their intellectual property is safe. You (the guy that runs a third party chip factory) cannot review or inspect the intellectual property that ARM gave you. The point here is that unless you're using an open source (RISC-V, etc) core, then using an ARM isn't really 100% open source hardware.
- Mask trojans & glitches - These are malicious things in the CPU die
itself, that even if you were looking at the silicon die under a microscope and studying it, you'd still completely miss it. Very nasty but they
Remarkable that you cannot do a verification using a microscope.
exist. Hackaday.com has a lot of interesting articles that break these sort of things down in layman's terms. Very interesting. Basically because these exist, there's no way to know that you are really executing what you think you are executing unless you built the foundry and supervised the chips being made, and analyzed everything that went into the manufacture of them. It's a trust problem.
These are all highly complex subjects that hardware engineers like Bunnie deal with a lot, and other (I'll say idealist) software guys probably have never thought of. They're important in that when you realize that they're there, you will then understand how silly wanting 100% open hardware really is. It's a huge problem that hardly anybody is trying to fix.
Recently the 6502 was completely dissected and recreated, so that's one of the only fully documented (and I'd say fully trusted) cores out there today. And that was made probably before I was born. Everything since that should be assumed to be compromised and < 100% open. Oh, and even then, the 6502 would have to hook up to OTHER chips like flash, RAM, and whatever generates the video and handles the peripherals. Those have not been completely dissected, and could be suspect. Do you see what Bunnie means now? That's the impedance mismatch.
We should have libre software hdds and ram.
P.S. my apologies to LKCL and others, I don't have a plain text email client. _______________________________________________ arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sun, Jun 11, 2017 at 4:38 PM, ronwirring@safe-mail.net wrote:
Thank you for the information. I have watched a rutkowska video on how complicated intel's management features are. Difficult.
That's why I'm here, lol. The Intel stuff is getting bad enough that it has me wondering what I can do for the open source hardware world. Moving to ARM via EOMA68 is a good near-term solution, but even that's not going to be 100% trustable at lest by bunnie's standards in the lecture. Something like RISC-V has the potential to get there, but as he pointed out, even that's not completely open. I think right now the important thing is to just be an early adopter of this stuff to show that the market's there. bunnie broke the demographics down pretty well, there's definitely money to be made. Back to Intel though. It makes me want to jump on eBay and pick up some older vintage Intel CPU's that didn't have the management features, but obviously there's no way to know if those aren't blown wide open by other means. Man, very interesting times we live in.
Remarkable that you cannot do a verification using a microscope.
You can do exactly this, and it'll get you to maybe 99% of the way there. Companies like ChipWorks do exactly this for money. Others do it for hobby (see: http://www.visual6502.org/, http://siliconpr0n.org/, https://zeptobars.com/en/, http://www.righto.com/). It can often get great results. bunnie was playing devils advocate by saying even if you did this, there are still things that can be present but in an obfuscated manner, that could be malicious or careless. This doesn't really mean to throw the baby out with the bathwater. Having a reverse engineered CPU with a small possibility of shenanigans is still better than having a 100% proprietary CPU or a 50% proprietary CPU. Security through obscurity and all that.
We should have libre software hdds and ram.
Can you elaborate on that a bit? I don't understand what you mean.
On Mon, Jun 12, 2017 at 1:02 AM, Neil Jansen njansen1@gmail.com wrote:
results. bunnie was playing devils advocate by saying even if you did this, there are still things that can be present but in an obfuscated manner, that could be malicious or careless.
there was a research paper a few years back which outlined that it would only take about 3,000 gates to compromise a processor (easily enough to implement a full RISC CPU).
that's about a million times less than what is in the current intel processors.
the point of the exercise was to illustrate how pointless it is do perform reverse-engineering of modern CPUs, given that the review process would be insanely complex and would almost certainly miss such obfuscated / hidden backdoors.
this is why both the chinese and the russian governments now design and make their own CPUs. in the case of china that's FROM SCRATCH. and using only trusted foundries.
l.
On Mon, Jun 12, 2017 at 3:26 AM, Luke Kenneth Casson Leighton <lkcl@lkcl.net
wrote:
this is why both the chinese and the russian governments now design and make their own CPUs. in the case of china that's FROM SCRATCH. and using only trusted foundries.
l.
I got a question: Assuming we got a decent design for a core( maybe based
on this https://github.com/ucb-bar/riscv-boom) , how would we deal with the rest of the ip blocks needed to run peripherals ? I assume the most complicated ones would be usb and ethernet, and I fail to see the point of a SoC without usb.
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Jun 12, 2017 at 9:53 AM, Bill Kontos vkontogpls@gmail.com wrote:
I got a question: Assuming we got a decent design for a core( maybe based on this https://github.com/ucb-bar/riscv-boom) , how would we deal with the rest of the ip blocks needed to run peripherals ? I assume the most complicated ones would be usb and ethernet, and I fail to see the point of a SoC without usb.
https://opencores.org/project,usb https://opencores.org/project,usbhostslave https://opencores.org/project,openarty for the UART (special, has debug capability) https://opencores.org/project,vga_lcd https://opencores.org/project,ddr3_sdram
i have the source for a linux kernel driver which uses that VGA/LCD hard macro: it was used by ICubeCorp for the IC3128. they ran it at too slow a speed so it would only do 1366x768 @ 30fps 8bpp: this is probably because the bus speed for the framebuffer access was too heavy for the Wishbone bus. ramping up the clockrate and/or using a larger bus width should fix that, but it will need checking.
also i believe the Gaisler Research LEON3 (SPARCv8) has an SMP implementation.
all of these are GPL licensed.... hilariously many people licensed their hard macros under the GPLv2 in the belief that nobody in their right mind would utilise GPLv2 hard macros for a commercial venture.
mwaahahahah
2017-06-12 2:02 GMT+02:00 Neil Jansen njansen1@gmail.com:
On Sun, Jun 11, 2017 at 4:38 PM, ronwirring@safe-mail.net wrote:
We should have libre software hdds and ram.
Can you elaborate on that a bit? I don't understand what you mean.
It's the same principle as explained by bunnie in the video. HDD and RAM process all the data. But they have hard/soft programming which proces that data.
If you can't audit the hard/soft programming then you don't know if your data is being read/copied/manipulated.
http://spritesmods.com/?art=hddhack
More and more hardware is using CPU to function. And thus have soft programming (firrmware) which can be altered.
arm-netbook@lists.phcomp.co.uk
-
Bill Kontos -
Luke Kenneth Casson Leighton -
mike.valk＠gmail.com -
Neil Jansen -
ronwirring＠Safe-mail.net