Communication btwn Linux User Space and Kernel Space.

 Source https://stackoverflow.com/questions/942273/what-is-the-ideal-fastest-way-to-communicate-between-kernel-and-user-space

• mmap

• named pipe

• system calls

• ioctls

• /proc & /sys 

• netlink

Reentrant vs Thread-safe

Source https://magicjackting.pixnet.net/blog/post/113860339

Reentrant vs Thread-safe

---

---

Reentrancy 和 thread-safty 是兩個容易被搞混了的觀念. 其中最嚴重的是誤以為 reentrant function 必定是 thread-safe 或者相反以為 thread-safe function 必為 reentrant, stackoverflow 網站上的答覆甚至同時出現二種答案的現象.

Reentrancy 和 Thread-safty 二者的差異

---

首先來看 reentrancy: 字面上的意思是可重入. Reentrancy 原先是討論單一執行緒環境下 (即沒有使用多工作業系統時) 的主程式和中斷服務程式 (ISR) 之間共用函數的問題. 當然現在多核心的 CPU 盛行, 討論範圍也必需擴充至多執行緒的情況. 重點是它討論的主體是: 在 ISR 中使用的函數 (不論是自己寫的或者是函數庫提供的) 是否會引發錯誤結果. 主要的達成條件是二者 (ISR 和非 ISR) 的共用函數中不使用靜態變數或全域變數 (意即只用區域變數). 一般是撰寫驅動程式 (device driver) 或者是寫 embedded system 的人會遇到這個問題.

再來是 thread-safety: 字面上的意思是執行緒 (線程) 安全. Thread-safe 一開始就針對多執行緒的環境 (CPU 可能單核也可能是多核), 討論的是某一段程式碼在多執行緒環境中如何保持資料的一致性 (及完整性), 使不致於因為執行緒的切換而產生不一致 (及不完整) 或錯誤的結果. 所以是程式中有運用到多執行緒的大型應用系統的程式人員會比較常遇到這類問題. 問題的產生點一般出現在對某一共用變數 (或資源) 進行 read-modify-write (或者類似的動作_(註一)) 時, 還沒來得及完成整個動作, 就被其他的執行緒插斷, 並且該執行緒也一樣對這個共用變數 (或資源) 進行 read-modify-write (或者類似的動作). 例如Thread1 和 Thread2 之間我們需要一個作為計數器的共用變數:

CR (Carriage Return, 0x0D = '\r') and LF (Line Feed, 0x0A = '\n')

 '\r'是回車，前者使游標到行首，（carriage return）ASCII碼（0x0D）

'\n'是換行，後者使游標下移一格，（line feed）ASCII碼(0xoA)

\r 是回車，return
\n 是換行，newline
對於換行這個動作，unix下一般只有一個0x0A表示換行("\n")，windows下一般都是0x0D和0x0A兩個字元("\r\n")，蘋果機(MAC OS系統)則採用回車符CR表示下一行(\r)

Unix系統裡，每行結尾只有“<換行>”，即“\n”；
Windows系統裡面，每行結尾是“<回車><換行>”，即“\r\n”；
Mac系統裡，每行結尾是“<回車>”,即“\r”。
一個直接後果是，Unix/Mac系統下的檔案在Windows裡開啟的話，所有文字會變成一行；而Windows裡的檔案在Unix下開啟的話，在每行的結尾會多車一個^M字元。
Dos和windows採用回車 換行CR/LF表示下一行,即^M$（$不是換行符的表示，換行符沒有表示出來，$是文字結束EOF的表示）
而UNIX/Linux採用換行符LF表示下一行，即\n
蘋果機(MAC OS系統)則採用回車符CR表示下一行，即\r

CR用符號'\r'表示, 十進位制ASCII程式碼是13, 十六進位制程式碼為0x0D;
LF使用'\n'符號表示, ASCII程式碼是10, 十六製為0x0A. 所以Windows平臺上換行在文字檔案中是使用 0d 0a 兩個位元組表示, 而UNIX和蘋果平臺上換行則是使用0a或0d一個位元組表示.

由於dos風格的換行使用\r\n，把這樣的檔案上傳到unix，有些版本的vi不能識別\r，所以vi顯示時在行尾會出現^M出來，但是有些就能識別\r\n，正常顯示回車換行。

Comparing the TEE to integrated HSMs

Source: https://www.trustonic.com/technical-articles/comparing-the-tee-to-integrated-hsms/

Introduction 

As more and more devices become connected so the need for ever greater security and protection of critical assets increases. Traditionally such support has been provided by a Hardware Security Module (HSM) but over the last decade the use of Trusted Execution Environments (TEE) has grown significantly. This article aims to provide the reader with an understanding of the difference between these two solutions and their suitability for different scenarios. 

HSM V TEE

Generically, a HSM provides key management and cryptographic functionality for other applications. 

A TEE also provides this functionality, along with enabling application (or security focused parts of applications) to execute inside its isolation environment. 

For example, in modern Android mobile devices, the TEE is already unknowingly used every day, by millions of people as an HSM equivalent, through the use of a Trusted Application (TA) providing the Android KeyMaster functionality. 

Regular Execution Environment (REE) is the term in the TEE community for everything in a device that is outside a particular TEE. Technically, from a particular TEEs point of view, all components that are outside of its security boundary live in the REE. Having said that, for simplification of the big picture, a device with multiple TEEs, SIMs, HSMs or other high trust components, may have those separated out from the REE. The REE houses the Regular OS, which in combination with the rest of that execution environment, does not have sufficient security to meet a task needed by the device. 

For more background on terminology like TEE and REE please have a look in “What is a TEE?” 

For more information on the ARM TrustZone hardware security behind the TEE have a look in “What is a TrustZone?” 

How a HSM solves your problems… 

In compact devices with integrated HSM, the software architecture looks something like this: 

The HSM provides Cryptographic Services to your security focused task. 

The “Secure” task in the REE has data. The HSM can receive that data and encrypt or decrypt that data, before handing it back to the issuer task in the REE. 

How is this done using a TEE? 

Here is how we support HSM functionality in a TEE enabled device today: 

In an Android device, the above HSM will typically be replaced by a TA, within the TEE, implementing Keymaster functionality and an Android specific REE stack rather than OpenSSL/PKCS#11. 

In the above case, with a simpler Regular OS as might be found in an Engine Control Unit (ECU), a generic TA has been specifically written to provide the functionality of a typical HSM. 

Of course, with a TEE you can always do better than that

A TEE need not be used as a fixed purpose service provider like an HSM, it can also host the tasks directly. 

Here we move the task into the TEE and manipulation of the unencrypted data can occur, in a place inaccessible to activity in the REE. 

As an example of what we gain:  

• A device typically supports other tasks like complicated communication protocols (e.g., CAN Bus, IP, BlueTooth or even 5G).  
• These communication mechanisms may, or may not, be used by a particular secure task. 
• What is important, is that by placing the secure task somewhere isolated from that communication software (e.g., in a TEE), security issues in the communication software no longer potentially drag down the security of the secure task. 

Some HSMs can load code to execute through proprietary extensions, but a GlobalPlatform compliant TEE uses standardised interfaces, enabling tasks developed for one TEE, to execute on another. Such tasks, executing in the TEE, are called “Trusted Applications”. 

What you cannot do with a HSM, but can do with a TEE in a well-designed SoC

HSM’s cannot directly protect the I/O ports providing sensor data, or controlling actuators, from software attacks in, for example, the REE of the ECU of a vehicle. 

Unlike an HSM, on a correctly designed System-On-Chip (SoC) a TEE can also interface to peripherals. This enables the creation of a secure task, housed safely inside the TEE,  that can be used to substantially enhance the critical tasks’ security.  

What do we gain here?  

Well, consider an example, from the automotive industry, of a fuel throttle. If the throttles’ I/O control port on the ECU is exposed in the REE software then it does not matter how much security the REE “Secure” task use of the HSM brings; you would not be using an HSM if you had high confidence in the security of the REE itself, and so you cannot have confidence that the software in the REE cannot be attacked.  

If the REE is open to attack, that means that attacked REE software can potentially gain unauthorised access to that I/O port, no matter how good the HSM is.  

In the TEE (like in an HSM), we do not have the generic load of software tasks unrelated to security. A task in the TEE can interface to hardware control ports without risk of other software making unauthorised access. 

If I only have an HSM in the above example, then all I can do is protect the data traffic to a device, not the decision making in the device. With a TEE, I can do both. 

Physical Attacks: TEE vs HSM 

As we have seen above, one issue with the use of an HSM is the exposure of data communications before any encryption has occurred. 

• This impacts the data while it is in software, where it can be extracted or modified by a corrupted REE before the HSM has had a chance to act upon it.  
• This also impacts the hardware attack profile. 

Fundamentally, device integrated HSMs might go as far as to use on-SoC hardware methods to protect their keys from extraction that are stronger than those of a TEE. However, the method to transfer data to the HSM for protection by those keys is no more strongly protected, than that used by a TEE and can be far weaker.  

Consider the following PCB-attached HSM in comparison to a typical TEE which will be using a stacked die (Package on a Package) to protect its much higher speed traffic: 

Physical attacks

Stronger TEEs do not even use external RAM, as shown above, but can use on-SoC RAM instead. 

TEE using On-SoC RAM

In this case, the benefit of using a TEE to provide traditional HSM functionality is a significant reduction in the exposure of unprotected data and therefore an enhancement of the overall security for the platform. 

Ultimately, if you are concerned about key extraction, it is advised that designs keep the key batch size small, whether using a TEE or an HSM. 

It is worth noting that in the EVITA standards, some HSM types reside on the same SoC as the REE, but in those cases their hardware protection methods are typically the same as a TEE (see the EVITA HSM levels). 

Conclusions 

In fast moving new innovation areas, such as connected vehicles and robotics, as well as consumer electronics devices, a TEE provides a cost effective and future proofed alternative to using an HSM. 

In addition to the potential of providing typical HSM functionality, a GlobalPlatform compliant TEE can also protect the critical tasks directly and has standardised methods for enabling over-the-air updating of critical systems. 

Fundamentally, a typical HSM is an attack-resistant cryptographic device designed to perform a specific set of cryptographic functions by the HSM designer. It provides the confidence of non-interference inside the scope defined by the relevant protection profile. A standardised TEE can do the same, and significantly more without the need to add additional hardware. As the TEE resides on the existing SoC integrated MMUs and TrustZone enabled hardware, the overall hardware bill of materials can be reduced and as components are being removed, and incidentally reducing risks of hardware failure.  

The development of TEEs is driven by standards, such as GlobalPlatform, and this brings predictability and interoperability. This means that device OEMs and third parties, can develop Trusted Applications to support an ever-growing list of platform security requirements.    

Ubuntu 14.04 使用 codeblock

Ref:https://www.itread01.com/p/160649.html 1、安裝 sudo apt-get install codeblocks codeblocks-common codeblocks-contrib wxformbuilder libwxbase3.0-0 libwxgtk3.0-0 wx-common wx3.0-headers wx3.0-i18n wx3.0-examples 2、基礎配置 http://wiki.codeblocks.org/index.php?title=Syntax_highlighting_custom_colour_themes 新增theme setting => syntax highlighting 配置theme setting => editor => margin and caret 配置游標顯示(預設為黑色,黑色theme時看不到) setting => editor => keyboard shortcuts 配置快捷鍵 setting => editor => code complete 配置程式碼自動完成 3、專案 file => new => project 建立專案 專案屬性 => build options 配置專案環境,tag,shared lib,標頭檔案等 file => new => file / class 新新增程式碼檔案 4、常用快捷鍵 ctrl + G 跳轉到某一行 alt + G 開啟某一檔案 ctrl + shift + G 跳轉到某一函式 ctrl + F9 編譯 ctrl + F10 執行 ctrl + F11 重新編譯 F9 編譯+執行 5、DEBUG Project > Set programs' arguments...

Handbook - QXDM

[Operating mode]

MSG 07:04:47.945 IMS/High [ICSDPLHandlerVOWIFIDisabled.cpp    484] ICSDPLHandlerVOWIFIDisabled::ProcessCallCtrlCB | oprt mode (lpm on/off, etc.) - 61                        ICSDPLHandlerVOWIFIDisabled.cpp00484                    ICSDPLHandlerVOWIFIDisabled::ProcessCallCtrlCB | oprt mode (lpm on/off, etc.) - 6

Extract the UBIFS images from a UBI image.

Source: https://github.com/jrspruitt/ubi_reader/blob/master/README.md#extracting-images

sudo apt-get install ubi_reader

ubireader_extract_files [options] path/to/file

The script accepts a file with UBI or UBIFS data in it, so should work with a NAND dump. It will search for the first occurance of UBI or UBIFS data and attempt to extract the contents. If file includes special files, you will need to run as root or sudo for it to create these files. With out it, it'll skip them and show a warning that these files were not created.