Tag: Linux

AMD’s Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV)

~ hucktech ~ Leave a comment

Linux is about to get more secure on some AMD systems, it seems… Tom Lendacky of AMD submitted an 18-part patch to many of the Linux dev lists, to add support for AMD’s new Secure Memory Encryption (SME) feature, and to prepare for an upcoming Secure Encrypted Virtualization (SEV) patch.

SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. Details on SME can found in the links below. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature. The approach that this patch series takes is to encrypt everything possible starting early in the boot where the kernel is encrypted. Using the page table macros the encryption mask can be incorporated into all page table entries and page allocations. By updating the protection map, userspace allocations are also marked encrypted. Certain data must be accounted for as having been placed in memory before SME was enabled (EFI, initrd, etc.) and accessed accordingly.

This patch series is a pre-cursor to another AMD processor feature called Secure Encrypted Virtualization (SEV). The support for SEV will build upon the SME support and will be submitted later.

AMD Memory Encryption whitepaper:

Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual:

Click to access 24593.pdf

SME is section 7.10
SEV is section 15.34

https://lkml.org/lkml/2016/4/26/1109
https://lkml.org/lkml/2016/4/26/1114
http://www.amd.com/en-us/innovations/software-technologies/security
http://www.amd.com/en-us/solutions/pro/security-manageability

For the patch, see the Linux-kernel or Linux-EFI (or other) lists:
http://vger.kernel.org/majordomo-info.html

Hardening Linux containers

~ hucktech ~ Leave a comment

https://twitter.com/alexstamos/status/722893515382915072

Aaron Grattafiori of NCC Group has just published research on Linux containers and security hardening.

[…] Our recently-posted whitepaper starts off exploring the various motivations behind Linux containers and how they contrast with more traditional hardware virtualization on modern general purpose CPUs. The whitepaper then explores Linux namespaces, cgroups, and capabilities in depth, listing example use and illustrating potential risks. Next is an in-depth discussion of the various threats to any container deployment, either container to host attacks, cross-container attacks,and other potential threats to any container deployment, regardless of size. To counter these threats and add future defense in depth, this whitepaper also includes an exploration of key security features such as user namespaces, seccomp-bpf and Mandatory Access Control. While these features are often discussed as they relate to containers, the protections can be applied to any Linux application, regardless of container deployment. After exploring container basics, threats, and security features, an overview of Docker, LXC and CoreOS Rkt is included. This overview covers the container solution background, key components and includes a brief security analysis of each platform. This section ends by contrasting different container defaults, before enumerating various security recommendations to counter weaknesses (both in general for any container platform, and specifically for LXC, Docker and CoreOS Rkt). These configuration tweaks, security actions, strategies and recommendations help establish hardened Linux containers and adding defense in depth to any application deployment. To conclude, a number of future related technologies are briefly explored such as unikernels, microservices and other container platforms, this also includes a discussion of hybrid container/hardware virtualization using minimal hypervisors. […]

Full paper:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2016/april/understanding-and-hardening-linux-containers/
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-10pdf

Intel to release SGX for Linux

~ hucktech ~ Leave a comment

Dan Zimmerman of Intel posted a status update regarding Linux availability of an SDK for Intel SGX:

Excerpting the blog:

The Intel intends to:
* Open-Source the Intel® SGX SDK for Linux* and associated Platform Software in June 2016.
* There will be a few user-space components where binaries will be provided instead of source

It sounds like this will be a freeware release that includes partial source, not a proper open source project. At least, I am not sure how it can be called “Open Source” if it includes a few binaries instead of source…

Going a bit off SGX-topic, in his blog post, Dan mentions:

“Whenever I talk with developers about Intel® SGX, one of the first questions asked is ‘When will Linux support be available’?”

I am glax Intel SGX team is paying attention to Linux. There are many other Intel teams that only pay attention to Windows. 😦

Full blog:

https://software.intel.com/en-us/blogs/2016/04/11/intel-software-guard-extensions-sdk-for-linux-availability-update

new Intel patch adding TCG OPAL unlock to Linux NVMe

~ hucktech ~ Leave a comment

Rafael Antognolli of Intel posted a patch to the Linux-(NVMe,Block,Kernel) mailing lists, adding TCG OPAL unlock support to NVMe:

Add Opal unlock support to NVMe. This patch series implement a small set of the Opal protocol for self encrypting devices. It’s implemented only what is needed for saving a password and unlocking a given “locking range”. The password is saved on the driver and replayed back to the device on resume from suspend to RAM. It is specifically supporting the single user mode. It is not planned to implement the full Opal protocol (at least not for now).

Add optane OPAL unlocking code. This code is used to unlock a device during resume from “suspend to RAM”. It allows the userspace to set a key for a locking range. This key is stored in the module memory, and will be replayed later (using the OPAL protocol, through the NVMe driver) to unlock the locking range. The nvme_opal_unlock() will search through the list of saved devices + locking_range + namespaces + keys and check if it is a match for this namespace. For every match, it adds an “unlocking job” to a list, and after this, these jobs are “consumed” by running the respective OPAL “unlock range” commands (from the OPAL spec):
  * STARTSESSION
  * SET(locking range, readwrite)
  * ENDSESSION

NVMe: Add ioctls to save and unlock an Opal locking range. Two ioctls are added to the NVMe namespace: NVME_IOCTL_SAVE_OPAL_KEY and NVME_IOCTL_UNLOCK_OPAL. These ioctls map directly to the respective nvme_opal_register() and nvme_opal_unlock() functions. Additionally, nvme_opal_unlock() is called upon nvme_revalidate_disk, so it will try to unlock a locking range (if a password for it is saved) during PM resume.

For more information, see the post on the list archives:
http://lists.infradead.org/mailman/listinfo/linux-nvme

Intel patch to Linux kernel for ACPI overlays

~ hucktech ~ Leave a comment

Octavian Purdila of Intel has posted a 10-part patch to the Linux-(ACPI,EFI,I2C,SPI,Kernel) lists, adding “ACPI Overlays” to the Linux kernel:

This patch set enables custom ACPI board configuration by adding mechanisms in the Linux kernel for loading user defined SSDTs. In order to support ACPI open-ended hardware configurations we need a way to augment the ACPI configuration provided by the firmware image. A common example is connecting sensors on I2C / SPI buses on development boards. Although this can be accomplished by creating a kernel platform driver or recompiling the firmware image with updated ACPI tables, neither is practical: the former proliferates board specific kernel code while the latter requires access to firmware tools which are often not publicly available. Because ACPI supports external references in AML code a more practical way to augment firmware ACPI configuration is by dynamically loading user defined SSDT tables that contain the board specific information.

This patch sets provides three methods for loading custom SSDTs:
1) From an EFI variable: This is the preferred method, when EFI is supported on the platform, because it allows a persistent, OS independent way of storing and updating the user defined SSDTs. There is also work underway to implement EFI support for loading user defined SSDTs and using this method will make it easier to convert to the EFI loading mechanism when that will arrive.
2) From the first uncompressed initrd (similar with the override functionality): This is useful when EFI is not supported on the platform and when it is not possible to defer the loading to userspace.
3) From userspace via configfs: This is useful when we want to defer the operation to userspace for platform detection, loading the SSDTs from a custom partition, etc.

Octavian Purdila (10):
  kernel: add TAINT_OVERLAY_ACPI_TABLE
  acpi: install SSDT tables from initrd
  acpi: add support for ACPI reconfiguration notifiers
  acpi: fix enumeration (visited) flags for bus rescans
  i2c: add support for ACPI reconfigure notifications
  spi: add support for ACPI reconfigure notifications
  efi: load SSTDs from EFI variables
  configfs: fix CONFIGFS_BIN_ATTR_[RW]O definitions
  acpi: add support for configfs
  acpi: add support for loading SSDTs via configfs

 Documentation/ABI/testing/configfs-acpi |  23 +++++
 Documentation/acpi/ssdt-overlays.txt    | 174 ++++++++++++++++++++++++++++++++
 Documentation/kernel-parameters.txt     |   7 ++
 Documentation/oops-tracing.txt          |   2 +
 Documentation/sysctl/kernel.txt         |   1 +
 MAINTAINERS                             |   1 +
 drivers/acpi/Kconfig                    |   9 ++
 drivers/acpi/Makefile                   |   1 +
 drivers/acpi/bus.c                      |  72 +++++++++++++
 drivers/acpi/configfs.c                 | 143 ++++++++++++++++++++++++++
 drivers/acpi/internal.h                 |   3 +
 drivers/acpi/scan.c                     |  73 +++++++++++++-
 drivers/acpi/sysfs.c                    |   6 +-
 drivers/firmware/efi/efi.c              | 107 ++++++++++++++++++++
 drivers/i2c/i2c-core.c                  |  38 ++++++-
 drivers/spi/spi.c                       |  36 ++++++-
 include/acpi/acpi_bus.h                 |   8 ++
 include/linux/configfs.h                |   4 +-
 include/linux/kernel.h                  |   1 +
 kernel/panic.c                          |   2 +
 20 files changed, 699 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/configfs-acpi
 create mode 100644 Documentation/acpi/ssdt-overlays.txt
 create mode 100644 drivers/acpi/configfs.c

For more information, see the full patch on the above-listed mailing lists.

Linux EFI bootloader control driver

~ hucktech ~ Leave a comment

Matt Gumbel of Intel has submitted a patch to the Linux-EFI and Linux-kernel lists, to add an EFI bootloader control driver to Linux:

efi: Introduce EFI bootloader control driver

This driver intercepts system reboot requests and populates the LoaderEntryOneShot EFI variable with the user-supplied reboot argument. EFI bootloaders such as Gummiboot will consume this variable and use it to control which OS is booted next. We use this with Android where reboot() tells the kernel that we want to boot into recovery or other non-default OS environment. It is the bootloader’s job to guard against this variable being uninitialzed or containing invalid data, and just boot normally if that is the case.

+config EFI_BOOTLOADER_CONTROL
+    tristate “EFI Bootloader Control module”
+    depends on EFI_VARS
+    default n
+    help
+      This driver installs a reboot hook, such that if reboot() is
+      invoked with a string argument NNN, “bootonce-NNN” is copied to
+      the EFI variable, to be read by the bootloader. If the string
+      matches one of the boot labels defined in its configuration,
+      the bootloader will boot once to that label.

For more information, see drivers/firmware/efi/efi-bc.c, the linux-efi or linux-kernel mailing lists:
http://vger.kernel.org/majordomo-info.html

Linux 4.6 to see UEFI improvements

~ hucktech ~ Leave a comment

https://twitter.com/FirmwareEngine/status/710460703048511488

http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01137.html

For the next Linux kernel, there are some new UEFI improvements to look forward to. Excerpting email from Ingo Molnar:

The main changes are:
– Use separate EFI page tables when executing EFI firmware code. This isolates the EFI context from the rest of the kernel, which has security and general robustness advantages. (Matt Fleming)
– Run regular UEFI firmware with interrupts enabled. This is already the status quo under other OSs. (Ard Biesheuvel)
– Various x86 EFI enhancements, such as the use of non-executable attributes for EFI memory mappings. (Sai Praneeth Prakhya)
– Various arm64 UEFI enhancements. (Ard Biesheuvel)

http://news.softpedia.com/news/linux-kernel-3-14-65-lts-improves-the-efivarfs-uefi-variable-filesystem-501828.shtml

ELC-EU’15 videos online

~ hucktech ~ Leave a comment

The videos for Embedded Linux Conference Europe 2015 are online. There are many interesting firmware and hardware-related presentations at this event.

For example, Simon’s talk on U-Boot driver models:

Order at Last: The New U-Boot Driver Model Architecture – Simon Glass

AMD microcode issue impacts Linux

~ hucktech ~ Leave a comment

[…] It happens only with 0x6000832 ucode, and Piledriver-based CPUs: i.e. newer AMD FX, and Opteron 300 series (4300, 6300 etc.). The visible effects are in ~80% of cases incorrect RSP leading to bad ‘rets’ into kernel data/bss or stack-protector faults. But there are also more elusive ones, like registers being cleared before use in indirect memory fetches or so. I can trigger it from within qemu guest (non-root), causing bad RIP in the host kernel. When testing, a couple of times (maybe 2) out of maybe 30 seen oopses, I was able to set it to user-space addresses mapped in the guest. It greatly depends on timing, but I think with some more effort and populating kernel stack with guest addresses it’d be possible to create a more reliable qemu-guest to host ring0 escape. I CC’d some AMD engineers from this list, and on of them replied with “We are working on the final testing of a new microcode patch to replace 0x06000832.” but without specifying any errata no, or ETA for the new ucode. […]

https://lkml.org/lkml/2016/2/26/876

Kali for Intel Edison

~ hucktech ~ Leave a comment

hackgnar has a new blog post out, showing how to build Kali for Edison targets:

Building Kali Linux for Intel Edison: This documentation goes though the process of manually building a base Kali Linux image for the Intel Edison board. These steps were derived from frankensteining the edison build scripts for Debian Jessie and some of the Kali Linux ARM build scripts. All of the content from this post can be found in my github repo for this project here, along with pre compiled images (coming soon!) and ansible scripts for automated building. Note, all of these steps were tested in Ubuntu Linux 14.04 x64 LTS. As of this writing, this OS/Version has the most support for doing Edison source builds. I have done these steps in other operating systems, but the process is not as clean due to bugs, script tweaks, etc. […]

http://www.hackgnar.com/2016/02/building-kali-linux-for-intel-edison.html
https://github.com/hackgnar/kali_intel_edison

NVIDIA signed firmware for Linux

~ hucktech ~ Leave a comment

http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Blobs-In-Linux-Firmware

http://www.linuxjournal.com/content/nvidia-releases-new-blobs-too-little-too-late

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=8d1fd61a3723ab8cb6b7bfeb8be38e16282cc1ed

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=c4f6a36d694bc4dbaeb6c9edae4889b4af2659ce

Linux UEFI systemd patch goes upstream

~ hucktech ~ Leave a comment

The Linux patch that protects from EFI and systemd is going upstream:

https://news.ycombinator.com/item?id=11152880

Merge branch ‘x86-urgent-for-linus’ of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:

“This is unusually large, partly due to the EFI fixes that prevent accidental deletion of EFI variables through efivarfs that may brick machines.  These fixes are somewhat involved to maintain compatibility with existing install methods and other usage modes, while trying to turn off the ‘rm -rf’ bricking vector.

Other fixes are for large page ioremap()s and for non-temporal user-memcpy()s”

* ‘x86-urgent-for-linus’ of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm: Fix vmalloc_fault() to handle large pages properly
  hpet: Drop stale URLs
  x86/uaccess/64: Handle the caching of 4-byte nocache copies properly in __copy_user_nocache()
  x86/uaccess/64: Make the __copy_user_nocache() assembly code more readable
  lib/ucs2_string: Correct ucs2 -> utf8 conversion
  efi: Add pstore variables to the deletion whitelist
  efi: Make efivarfs entries immutable by default
  efi: Make our variable validation list include the guid
  efi: Do variable name validation tests in utf8
  efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad version
  lib/ucs2_string: Add ucs2 -> utf8 helper functions

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0389075ecfb6231818de9b0225d3a5a21a661171

AMI adds Linux Ext2/Ext4 support to Aptio

~ hucktech ~ Leave a comment

AMI has Linux file system support in their UEFI implementation! I hope ZFS is also on AMI’s radar. 🙂

American Megatrends Adds Support for EXT(x) File System in Aptio V

American Megatrends Inc. (AMI) is offering EXT(x) file system support in Aptio V, an additionally licensed component driver. File systems keep track of information on storage mediums and there are various file systems that are used by different operating systems such as Windows and Linux. Normally at the UEFI firmware level, the legacy FAT (File Allocation Table) file system is supported. In order to overcome limitations of early file systems, the Linux community created the EXT file system. Over time, the EXT filesystem has gone through four revisions (EXT, EXT2, EXT3 and EXT4) and is specifically designed to improve storage space and performance. Support for different file systems has been added to Aptio over time and the EXT(x) file system joins as the newest addition. With the new support for EXT(x) drivers, any EXT(x) formatted media can be accessed by the UEFI firmware. This addition allows for files to be read and UEFI programs to be executed from EXT(x) media. Customers have the ability to develop pre-boot applications without having to provide a separate FAT file system, making the process simpler and more seamless. The new EXT(x) driver is designed to be read-only to support all EXT versions and to maintain filesystem integrity.

http://ami.com/products/bios-uefi-firmware/aptio-v/
http://ami.com/news/press-releases/?PressReleaseID=352

Intel Linux Perf team’s 0-Day project

~ hucktech ~ Leave a comment

The Intel open source site, 01.org, hosts the Linux Kernel Perf project, and they have a 0-Day project.

https://twitter.com/mcgrof/status/698175557423362049

[…] The infrastructure we developed to test the Linux kernel is called 0-Day.  It is a service and test framework for automated regression-testing that intercepts kernel development at its earliest stages, and is available to the worldwide Linux kernel community. This project provides a further “shift-left” by testing key developers’ trees before patches move forward in the development process. Some key features of 0-Day are:

* Provides 1-hour response time around the clock, hence the 0-Day name.
* Performs patch-by-patch tests
* Covers all branches of a developer’s tree
* Performs kernel build and static semantics-level testing using industry static source code analyzers
* Performs boot tests, functional and performance tests on a variety of IA-based platforms in our labs
* Bisects code automatically when tests fail, or when performance regresses, enabling us to identify which patch caused the failure.

More info:
https://lists.01.org/mailman/listinfo/lkp
https://01.org/lkp

I just learned about this, and don’t know much about it yet, It sounds interesting, “performs boot tests”. Maybe it is the Intel version of ARM/Linaro’s LAVA?

Protecting Linux from systemd’s EFI attack

~ hucktech ~ Leave a comment

Peter Jones of Red Hat has submitted a patch to the Linux-EFI mailing list, which helps with the recent systemd attack against Linux’s EFI. Patchset email excerpted below:

Preventing “rm -rf /sys/firmware/efi/efivars/” from damage

Here’s a patchset to make all the variables in efivarfs that aren’t well known to be reasonably safe to delete be immutable by default. This should alleviate the danger of somebody accidentally using “rm” to remove some proprietary file that turns out to be important to the platform, which for some reason it also can’t regenerate during POST. In all cases this is just preventing the user from accidentally triggering a major security problem with their underlying firmware, but stopping accidents isn’t a bad thing.  These firmwares still need CVEs and updates to fix them.  Maybe using ESRT and fwupd 🙂

For more information, see the linux-efi mailing list archives.

Systemd, UEFI, and efivarfs bricking concerns

 

Dell info on Linux firmware updates

~ hucktech ~ Leave a comment

Regarding the new firmware update service available for Linux OEMs:

https://firmwaresecurity.com/tag/fwupd/

There is a new article from Dell on this topic:

(Published on behalf of Mario Limonciello, OS Architect of Dell Client Solutions Group’s Linux Engineering team.)

I’m happy to announce that starting with the Dell Edge Gateway 5000 we will be introducing support to natively flash UEFI firmware under Linux.  To achieve this we’re supporting the standards based UEFI capsule functionality from UEFI version 2.5.  Furthermore, the entire tool chain used to do this is open source. Red Hat has developed the tools that enable this functionality: fwupd, fwupdate, & ESRT support in the Linux kernel.  For the past year we have been working closely with Red Hat, Intel, & Canonical to jointly fix hundreds of issues related to the architecture, tools, process, and metadata on real hardware.  Dell will be publishing BIOS updates to the Red Hat created Linux Vendor Firmware Service (LVFS).  Red Hat provides LVFS as a central OS agnostic repository for OEMs to distribute firmware to all Linux customers. […]

http://en.community.dell.com/techcenter/b/techcenter/archive/2016/02/02/dell-firmware-updating-under-linux

Dell — along with Red Hat, apparently — are setting a great example, I hope other OEMs do as well with Linux. 🙂 It makes me think Dell is working to deal with this recent comment of William (of Dell):

Linux ACPI to IBM and Lenovo: help!

~ hucktech ~ Leave a comment

If you know someone at IBM or Lenovo, the Linux-ACPI community needs more involvement from you, please help.

 

——– Forwarded Message ——–
Subject:     ibm-acpi developers not responding despite serious bugs and debuggers
Date:     Sat, 30 Jan 2016 13:22:27 +0000
From:     jono <lejono@gmail.com>
To:     Rafael J. Wysocki <rafael@kernel.org>
CC:     ACPI Devel Maling List <linux-acpi@vger.kernel.org>, ibm-acpi-devel@lists.sourceforge.net

Dear Rafael,
Sorry to trouble you, but a number of us are having lots of grief
getting a response from ibm/lenovo regarding acpi bugs in newer models
like the Helix 2. The bugs make these machines difficult to use, and
there are various reports of this on the internet, along with people
willing to debug patches. But it’s impossible to contact anyone on the
ibm-acpi team to help with this. Do you know who we can contact to
help sort these bugs out? Myself and others are polite, fairly tech
savy, and willing to help, so I’m a bit puzzled by the silence from
this team.

The example is the Helix 2, see:
https://bugzilla.kernel.org/show_bug.cgi?id=100171

and various repetitions of this…
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1424088
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1520965?comments=all

For more information, see the Linux-ACPI mailing list archives on kernel.org

http://vger.kernel.org/majordomo-info.html

AArch64 Xen gets Dom0 ACPI support

~ hucktech ~ Leave a comment

Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. The corresponding Xen patches can be fetched from [2].

  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3
http://vger.kernel.org/majordomo-info.html

Intel Memory Protection Extensions (MPX) documentation available

~ hucktech ~ Leave a comment

https://twitter.com/intelswfeed/status/689591155516923904

https://software.intel.com/en-us/articles/intel-memory-protection-extensions-enabling-guide

Intel® Memory Protection Extensions Enabling Guide

This document describes Intel® Memory Protection Extensions (Intel® MPX), its motivation, and programming model. It also describes the enabling requirements and the current status of enabling in the supported OSs: Linux* and Windows* and compilers: Intel® C++ Compiler, GCC, and Visual C++*. Finally, the paper describes how ISVs can incrementally enable bounds checking in their Intel MPX applications.