Roborace Showcase at MCity

On last Friday, which was May 21st, Roborace visited Mcity in the University of Michigan to show case its autonomous race car, Robocar. Robocar's first impression was astounding. Previous self-driving cars involved regular cars with regular seats. However, this race car was designed so that there is no seat. It looked like Formula 1 race cars with a higher cool factor.



To achieve the autonomy, the race car uses a combination of Lidars, Radars, Sonars, and computer vision cameras. Unlike traditional self driving cars which has a roof mounted Lidar, Robo race has a couple of Lidar in the front wheel wells. I wonder the benefits of the side mounted Lidars over top mounted Lidars. I predict that due to its low height, top-mounted Lidar might cause a line of sight issue. As a consequence of side mounted Lidar in the front, the car introduces a blind spot due to large back wheel wells. Therefore, the back wheel is mounted with Sonars to compensate. In the top of the car seats the computer vision camera.

V2V and autonomous vehicle development is growing rapidly. This brings potential security problems into questions. Vehicle security has been getting attentions recently with security vulnerabilities such as unauthorized CAN access. An introduction of new protocols such as DSRC and other proprietary radio signals for autonomous car communications may shine more surfaces for attacks and hacking. If we were to bring autonomous cars into market, solving and preventing security issues for autonomous cars is an important task.

Comments

Post a Comment

Popular posts from this blog

Let’s Build 5V Solar Charger

Image
I am taking an online summer class at University of Minnesota regarding renewable energy. I took a project of building a solar charger to charge my bike LED light. This will be a fun small project. The items used for this project are Adafruit phone charger kit and 6V 1W solar panel.               The above kit is a basic step-up converter circuit PCB that converts a variable input voltage to 5V output. It is meant to use two 1.5V battery cells. However, for this project, I will use a solar panel instead. The solar panel is advertised to output 6V. According to the LTC1302 datasheet of the boost converter used in this kit, the input voltage has a range from 2V to 8V. Therefore, this solar panel rated for 6V output should be appropriate for this build. I soldered all the parts according to the instruction here: https://learn.adafruit.com/minty-boost/solder-it . This is an easy task to people who have prior experience with soldering. Next week, I will demo
Read more

Single Sided Rowhammer Attack

Image
Today, I would like to run through the Rowhammer test code that Google Project Zero posted in its Github repository . This blog post will focus on the single sided Rowhammer using random address selection because it is simple and can be understood without knowledge in the LINUX system side of things. Rowhammering is an exploit in modern DRAMS due to high density of cells that reside in the memory device. More can be read in the Google Project Zero’s blogpost . The intention of this blog post isn’t to analyze the single-sided row hammer attack, but to explain briefly how the program works. So how does this code work? The program first allocates 1GB of memory. Then, in a tight loop, random eight addresses are chosen from the heap. At one address at a time, the program reads data (should be zero) from the chosen addresses. Google chose to read from a memory to a variable to replicate accessing a memory address. While not as fast as using x86 ‘mov’ assembly, the C instruction is st
Read more

Single Sided Rowhammer Attack Part 2

In the last blog, I posted about the probabilistic nature of the single sided Rowhammer attack due to its random address selection. This week, I found that allocating more heap increases the frequency of bit flips. From my experiment, allocating 14GB memory instead of 1GB increased the chance of successful bit flips by more than 20 times. Google’s single sided row hammer test source code initializes 1GB of memory. My prediction is that the OS randomizes the virtual memory mapping to multiple areas of physical memory address. Therefore, when relatively small amount of memory is allocated, for example 1GB out of 16 GB, the memory will likely spread over multiple banks. Therefore, when a pair of addresses are accessed and flushed, they won’t meet the requirement that the addresses are in the same bank and different row. Furthermore, when the row hammer attack does successfully flip a bit, it can be outside the allocated space. In this case, we won’t able to check the result, unless
Read more