diff --git a/blog/content/post/2020-02-01-3mdeb_at_fosdem2020_report.md.md b/blog/content/post/2020-02-01-3mdeb_at_fosdem2020_report.md.md new file mode 100644 index 000000000..e86ca29bd --- /dev/null +++ b/blog/content/post/2020-02-01-3mdeb_at_fosdem2020_report.md.md @@ -0,0 +1,350 @@ +--- +title: 3mdeb at FOSDEM 2020 report +abstract: 'Abstract first sentence. + Abstract second sentence. + Abstract third sentence.' +cover: /covers/image-file.png +author: piotr.krol +layout: post +published: true +date: 2020-02-01 +archives: "2020" + +tags: + - fosdem + - conference +categories: + - Firmware + - Miscellaneous + - Security + +--- + +On Saturday, with Michał Żygowski, we decided to go to Hardware aided Trusted Computing devroom. + +Some general considerations: +1. We would like to have disposable laptops available for 3mdeb employees +2. Laptop should give secure access to comapny infrstructure for employees, which can be easily wipe out +3. There should be support for high-end security features SRTM+DRTM +4. Laptop would be wiped every time we getting back from conference + +How secure access from unknown location would look like? +- we need tamper proofs after getting though custom clearance +- attestation to USB crypto token + +# Be secure with Rust & Intel SGX + +First presentation was from UC Berkley Ph.D. about Rust and SGX, the thesis is +that most CVE detected in M$ products are releated to memory safety, because of +that Rust is the language that address most of issues related with it. + +Rust: +- type safety +- statuc analysis built right into +- convinient error handling + +Parsing is easy with anything except C. Rust has good features support that. Of +course enclave code should contain mininimal parsing code. + +In architecture we should consider secure enclave as server, with that +attestation an identity is easy. + +In general presentation was pitch about EDP Fortanix, which is SGX+Rust+Srevice +API, which simplifies interaction between secure enclave and system. + +During demo was show how simple it is to run sample program in Rust in secure SGX encalve. + +There was extensive discussion including concerns about all recent SGX +vulnerabilitie and if in that light keepeing private key in enclave is till +secure, the answer was more about mitigations +- update your microcode to most recent (to the one that contain fix) +- reprovision with new key in case of any issues + +# The Confidential Consortium Framework + +A framework to build secure, highly available, and performant applications that focus on multi-party compute and data + +Second was from M$(?) CCF, in general it was about multi-party applications. We +would like to achive ditributed trusted computing (encyrpted integrity +proitected memory, remote attestation). + +It looks like everywhere there is discussion about TLS session which terminates +in secure enclave, this is to hide traffic against host that enclave running +on. There is still need for time source, time is fetched from host and is not +considered trusted. + +Key point of the system was to describe how mutli-party application can work in +similar was we set ruling, for example architecture can have voters that decide +about various things e.g. adding user changing community rules etc. It looks +like presentation discussed implementation/design of decision making system. +Of course everything use enclaves and secure communication. + +Other case is code update, so based on votes we can decide if new version is +acceptable to be used, if there is different result we recover to previous +version. Definitely whole talk was focused on cryptocurrency related use cases. + +Attestation relies on Intel attestation server, but M$ got their own and AFAIK +anyone can setup its own based on + +# Break for discussion with Daniel Kiper and dev room organization + +Meanwhile we discussed with Daniel about devroom , took devroom organizer +t-shirts. Daniel rise important question about TrenchBoot in light of Intel +TXT, about teardown of DLME and I started to wonder how this applies to AMD. + +# A tale of two worlds + +I get back to Hardware aided Trusted Computing, for attack-oriented talk. Room +was full of people at tis point. + +Talk based on paper.:w + +Interface is where attackers are intersted in (its like in old fortress break +in). Presenter also show comparison of various TEE enclaves and mentioned that +there are 5 CVEs coming which are under embargo. + +Trusted computing in cotect of this room concentrate on secure enclaves, why? +Probably because everyone already things systems and platforms are doomed. + +There are couple classes of attacks we should care, hypervisor attacks, CPU +attacks and enclave attacks. Solution for first class is secure enclave, +malusious hypervisior should no access content of enclave. Second class is +problematic, but not easy to exploit and we believe hardware vendors solve that +at some point. Third class is laos interesting and this is what about this tlak +was. It happen that interface to enclave can be buggy and this can be exploited +much simpler then other calsses. + +Let's imageing we can have some ABI at the entrance of enclave that can +validate what coming to enclave and expose some API to application inside +enclave. This design split responsibilities in enclave. + +There are many vulnerabilities across TEEs related to flags, stack pointeres +and registry leakage. More complex is CPU architecture more attack vectors and +problems you may face. RSIC-V seem to be good place to go here. + +In x86 you can change bahvior of instruction by CPU flags (RFLAGS.DF). What can +go wrong, before entering enclave bad actor can set that flag, this may cause +memory corruption inside enclave. there is also AC flag, which is alginment +check. This can be helpful in side-channel attack since it leaks bit of +information about code in enclave each time alignment exception is triggered + +On the another level, after enclave ABI level, there is API provided inside +enclave. For example you can pass pointer to encalve that points to untrosted +world, but malcious actor can replace pointer with adddress of something what +is inside secure world. Interestingly this attacks works. + +There are some other attacks based on IRQ handler lookop and execution time, +there was special framework created for that called sgx-step. + +From TEE frameworks Rust-EDP seem to be quite good quality. Very good talk over +all. Presenter advocate for RISC platform, but TEE thinga are not so +production-ready as advertised. Key point is that TEE is based on CISC. + + +Interesting things to check: +- sancus 16-bit open source hardware processor for enclaves + +# Pengutronix: building products with OP-TEE + +Pengutronix doing integration of OP-Tee into BSPs. This talk was about +TrustZone and started with idea how things work. + +Pengutronix worked mostly on i.MX6 integrating OP-TEE. There is also support +for RPi3 in OP-TEE. Motivation for talk is to secure and harden OP-TEE for +production workloads. Also make sure that fixes are contributed back. The idea +is that atendees may help fixing problems and implmenting features for STM, TI +and other not yet well suported solutions. + +It is important to add some protection of RAM for secure world behaving like +DDR fiewall. Upstream dirver for that is already implmented. In I.MX6 there is +TZC3809 controller. + +i.MX6UL may not have enough SRAM. This talk definitely contain lot of valuable +things that we can leverage for our customers using NXP. + +QUestions from me: + +1. Did Pengutronix perform any DMA attacks against OP-TEE on i.MX6? If yes can you reveal details. - not yet tried. +2. Musterinf enable bit in i.MX6 + +# Demo: SGX-LKL + +All problems in enclaves lead to generation of more frameworks containgin shim +laher that separate internal application in enclave from external interface by +adding sanitizing and checks on the boundary, Use muslc as libc used in side +enclave. + +It supports features like fiulesystem in enclave disk encryption and integrity, +Has limited interface with host and remote attestation. + +Demo show Wireguad VPN between 2 enclaves. + + +## Open Source Firmware, Bootloaders and OpenBMC devroom + +This room was created as collaboration between Piotr Król (3mdeb) and Daniel Kiper (Oracle, GRUB). Room was great success. + +### Open source UEFI and TianoCore + +### Discover UEFI with U-Boot + +This was very interesting talk how to solve some problems of bootloader +ecosystem fragmentation and fact that some projects already implemented +features needed for others. + +### Heads OEM device ownership/reownership : A tamper evident approach to remote integrity attestation + +Current status and future plan : A call for collaboration + +### Improving the Security of Edge Computing Services + +Update status of the support for AMD and Intel processors + +### Introducing AUTOREV + +An automatic reverse-engineering framework for firmware BLOBs + +### Look at ME! + +Intel ME firmware investigation + +### Capsule Update & LVFS: Improving system firmware updates + +Improving reliability and security by simplifying distribution of firmware updates + +### Opening Intel Server firmware based on OpenBMC example + +# Day 2 + +## BSP generator for 3000+ ARM microcontrollers + +AdaCore company representatives gave talk about MCUs supported by Ada, there +are over 4000 supported MCUs. Talk discussed how ecosystem managed to add so +many MCUs and keep sanity. + +Interesting is SPARK. + +CMSIS: +- set of software interfaces for debugging, drivers, RTOS, neural networks, + DSPs and more +- packs - the way to distribute software packages, there are PDSC (MCU details) + and SVD (peripherals description) + +How all that data can be used? +- SVD2Ada +- startup-gen - use PDSC XML files to prepare Ada GPR files + +At this point they can create Ada/SPARK binding (BSP) for any Cortex-M microcontroller. + +Embedded Rust people developing vey similar project. + +## On-hardware debugging of IP cores with free tools + +Verilog and VHDL use depends on what side of Atlantic you are ;) +Free software is available for HDL developers. + +Common way to debug hardware is blinking LED. + +Tlak was very well prepared showing various approaches to FPGA programming and +debugging. + +TCL is still used by Verilog/VHDL developers in similar way as regular +developers use make. Most important work that should be done is tools +integration. + +## Continuous Integration for Open Hardware Projects + +OpenTec Gmbh founder as well as co-founder of FOSSASIA. They started Pocker +Sicence Lab project. There is Android associated application and device can be +used as many measuring tools. + +Other project is drawing on led badge. Another one is Neurolab which collects +brain waves for checking the mood and/or related data. + +CI for hardware, the goal for CI is to reduce the time of integration. + +There are many things to do to improve building hardware +- testing +- BOM creation automation +- + +## Open Source Firmware Testing at Facebook + +If you don't test your firmware, your firmware fails you + +This talk was very crowded, this talk was sent for open source firmware +devroom, but we rejected it mostly because of too many talks. + +One of the goals of Facebook infrastructure plan to be generic. They claim that +due diligence and no system fulfilled their needs. + +Unfortunately our opinion is that this project contribute to automated +validation systems market fragmentation and will cause more problems to have +interoperability between systems. We are not exactly understand why not to +follow LF Automated Testing group effort. + +## AMENDMENT How to run Linux on RISC-V + +with open hardware and open source FPGA tools + +RISC-V foundation is Switzerlang. lowRISC working with Google on OpenTitan, but +organization do intreesting things and they have RISC-V implementation which an +be flashed on FPGA and boot Linux. + +This is another presentation overviewing topics in this focus on RISC-V. It is rather call for participation then anything innovative. + +There was information about cheap RISC0V (13USD) K210, which can boot Linux, +unfortunately tis is NOMMU platform. The way to go now is QEMU. + +These year there are 3 processors that coming. + +NXP working with open hw group to create: +http://linuxgizmos.com/linux-driven-risc-v-core-to-debut-on-an-nxp-i-mx-soc/ + +There were many intresting things in this presentation for anyone intrested in RISC-V and FPGA. + +## A free toolchain for 0.01 € - computers + +The free toolchain for the Padauk 8-bit microcontrollers + +Niche talk although probably because of title gathered audience. It was call for participation in SDCC compiler, which is used for + +## Status of AMD platforms in coreboot + +Michals talk gathered quite a lot of people interested in history of AMD in +coreboot. This was not first talk that had problem setting up the screen. + +Michal started with terminology and moved with history of hardware and how +coreboot supported those various platforms across time. + +Over all Michal presented what would be the plans of 3mdeb in area of +supporting old boards. + +## Open Source Hardware for Industrial use + +OSHW model has benefits for SOC vendors, industrial manufacturers and end users + +This talk was by Olimex + +Talk was very interested with lot of laughs, becaue of ridiculous istuation and +lack of understanding from Allwinner about open source hardware. + +Olimex made a lot of industrial projects with long term support. + +Plans: +- powerful NXP board (LPDDR4) it would not be cheap, but more like, ARM-based server i.MX8 MAX +- aluminium body laptops are on roadmap +- also work with STM + + +## Summary + +Summary of the post. + +OPTIONAL ending (may be based on post content): + +If you think we can help in improving the security of your firmware or you +looking for someone who can boost your product by leveraging advanced features +of used hardware platform, feel free to [book a call with us](https://calendly.com/3mdeb/consulting-remote-meeting) +or drop us email to `contact3mdebcom`. If you are interested in similar +content feel free to [sing up to our newsletter](http://eepurl.com/gfoekD)