Uncategorized

UEFI UDK2017 pre-release available

Brian Richardson of Intel announced a pre-release of UDK2017, a snapshot of the Tianocore.org EDK2 trunk code matching a set of UEFI.org specs.

Information on UDK2017, the next stable snapshot release of EDK II, is available on the TianoCore wiki.

From the release page on the wiki, here’s the list of

UDK2017 Key Features
    Industry Standards & Public Specifications
        UEFI 2.6
        UEFI PI 1.4a
        UEFI Shell 2.2
        SMBIOS 3.1.1
        Intel® 64 and IA-32 Architectures Software Developer Manuals
    Storage Technologies
        NVMe
        RAM Disk (UEFI 2.6, Section 12.17, RAM Disk Protocol)
    Compilers
        GCC 5.x
        CLANG/LLVM
        NASM
    OpenSSL 1.1.0
    UEFI HTTP/HTTPS Boot
    Adapter Information Protocol
    Regular Expression Protocol
    Signed Capsule Update
    Signed Recovery Images
    SMM Communication Buffer Protections
    STM Launch
    Memory Allocation/Free Profiler
    NX Page Protection in DXE
    LZMA Compression 16.04
    Brotli Compression
    MP Init Library

https://github.com/tianocore/tianocore.github.io/wiki/UDK2017

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

Standard
Uncategorized

20+ China-based companies join UEFI Forum

They could have at least included the list of the 20+ companies in the press release. ;-(

In anticipation of the first China-based UEFI event in ten years, over 20 new members in China joined the UEFI Forum—indicating significant interest in UEFI technology in the greater China region. Additionally, in attendance from the region were prominent member companies including H3C and Inspur, Lenovo, Loongson Technology Corporation Limited, and Sugon.

http://finance.yahoo.com/news/20-china-based-companies-join-020000847.html

http://uefi.org/members

Standard
Uncategorized

UEFI Plugfest slides uploaded

https://uefi.blogspot.com/2017/03/uefi-plugfest-2017-in-nanjing.html

Tim Lewis of Insyde has a blog post with an update for the UEFI plugfest. *Multiple* presentations on security!!

 State of UEFI – Mark Doran (Intel)
 Keynote: China Information Technology Ecosystem – Guangnan Ni (Chinese Academy of Engineering).
 The Role of UEFI Technologies Play in ARM Platform Architecture – Dong Wei (ARM)
 ARM Server’s Firmware Security – Zhixiong (Jonathan) Zhang, Cavium
 SMM Protection in EDK II – Jiewen Yao (Intel)
 Server RAS and UEFI CPER – Mao Lucia and Spike Yuan (Intel)
 A More Secure and Better User Experience for OS-based Firmware Update – David Liu (Phoenix)
 UEFI and IoT: Best Practices in Developing IoT Firmware Solutions – Hawk Chen (Byosoft)
 Establishing and Protecting a Chain of Trust with UEFI – David Chen (Insyde)
 Implementation of Hypervisor in UEFI Firmware – Kangkang Shen (Huawei)
 Lessons Learned from Implementing a Wi-Fi and BT Stack – Tony Lo (AMI)
  UEFI Development Anti-Patterns – Chris Stewart (HP)

http://www.uefi.org/learning_center/presentationsandvideos

Standard
Uncategorized

ACPI registry updates

It looks like there have been 3 new ACPI regisrations so far this year:

Coreboot Project     BOOT     02/28/2017
https://www.coreboot.org/

Exar Corporation     EXAR     02/28/2017
https://www.exar.com/

VR Technology Holdings Limited     3GVR     01/19/2017
http://www.3glasses.com/en/

http://www.uefi.org/acpi_id_list

Standard
Uncategorized

UEFI-Bootkit

I just noticed a new UEFI bootkit on Github which I’d never heard of:

“UEFI-Bootkit: A small bootkit designed to use as little ASM as possible. Thanks to pyro666”

https://github.com/dude719/UEFI-Bootkit

I sent a FYI to the UEFI Security group before posting about it to this blog, in the name of responsible disclosure. Dick Wilkins of Phoenix Technologies– and of the UEFI Forum’s Security Response Team (USRT) — replied with his input on the code:

“I just took a quick look at this code in github. It looks like the typical UEFI application that changes the configuration and could cause unexpected things to boot. The unexpected stuff could damage the system and then continue to boot up normally but compromised. This is exactly why Secure Boot was needed. If Secure Boot is disabled (or not implemented), there are many ways to insert code into the boot path and compromise a system. If Secure Boot is enabled, this code and any code like it would not be properly signed and would never run. There is nothing new here. This is why end users must be discouraged from disabling secure boot and running non UEFI Secure Boot aware systems.”

http://www.uefi.org/security

Standard