Category: Uncategorized

FWTS 15.12.00 released

~ hucktech ~ Leave a comment

Alex Hung of Canonical has announced the quarterly release of 15.12.00 of FirmWare TestSuite (FWTS). Besides updating to ACPICA to 20151124, it includes the following new features, including a handful of new UEFI features:

  * live-image/fwts-frontend-text: add a selection for recommended
  * data: klog.json: add in some more kernel error messages for 4.3
  * ACPI: Add ASPT test
  * lib: framework: allow mixed tests and test category options
  * fwts: framework: Add –log-level option
  * lib: fwts_uefi: add SD device path define
  * Boot path sync with UEFI spec. 2.5
  * uefibootpath: add test for the SD device path
  * uefidump: add dumping for the SD device path
  * lib: fwts_uefi: add efi bluetooth device path define
  * uefibootpath: add test for the bluetooth device path
  * uefidump: add dumping for the bluetooth device path
  * lib: fwts_uefi: add wireless device path define
  * uefibootpath: add test for the wireless device path
  * uefidump: add dumping for the wireless device path
  * lib: fwts_uefi: add ramdisk device path define
  * uefibootpath: add test for the ramdisk device path
  * uefidump: add dumping for the ramdisk device path

See full announcement for list of bugs fixed in this release.

https://launchpad.net/ubuntu/+source/fwts
http://fwts.ubuntu.com/release/fwts-V15.12.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/15.12.00

Philips firmware blocks third party vendors

~ hucktech ~ Leave a comment

Wow, you’ll need to root your lamp and home lighting system soon, if Philips gets their way.

http://www.techhive.com/article/3015187/connected-home/philips-hue-users-outraged-after-firmware-update-blocks-third-party-lightbulbs.html

[…]

But here’s the kicker. Literally. Philips has just slapped fans like us in the face and kicked interoperability out the door. Without any communication they delivered a new firmware to the system that disables adding products that they don’t approve of. Basically they are banning other Zigbee Light Link products despite the fact that they are a Connected Lighting Alliance member whose mission is to promote interoperability.
As it seems (and unless this is just a huge mistake on Philips’ side), they have without a warning turned their open product into a walled garden. They have also destroyed the value of the solutions that the customers have set up based on Philips’ promises.
And the worst thing is that Philips has done this to their most enthusiastic fans. To the early adopters. To those who enthusiastically recommended the system to their friends.
Way to go, Philips. Way to go.
If you are in the same boat, here are links to a few places to complain or discuss:
[…]
Update: I’ve just seen the first mention by someone on the Philips Hue Developer Forum if anyone knew a lawyer who could look into this from a class action lawsuit point of view, as Philips did false advertising and a bait and switch here. Things are heating up.

Full post:

http://soapbox.chrismarquardt.com/post/disconnected-lighting-alliance

http://theconnectedlightingalliance.org/members/members-overview/philips/
http://www.theconnectedlightingalliance.org/about-us/mission-scope/

http://www.developers.meethue.com/content/friends-hue-program-update

Grub2 exploitable

~ hucktech ~ Leave a comment

Warning, GRUB2 has some input issues:

https://twitter.com/hdmoore/status/676790505783615488

Authors:    Hector Marco & Ismael Ripoll  —  Cybersecurity Group
CVE:    CVE-2015-8370
Comment:    Grub2 Authentication Bypass 0-Day
Dates:     December 10th, 2015 – Disclosed at IX Jornadas STIC CCN-CERT.
December 14th, 2015 – Published in the web.

http://hmarco.org/bugs/CVE-2015-8370-Grub2-authentication-bypass.html

Bypassing ALSR on GLibC (at build time)

~ hucktech ~ Leave a comment

Rich Felker notes that Glibc — the GNU C standard library implementation — usage and how it impacts ASLR security:

[PATCH] Add Prefer_MAP_32BIT_EXEC for Silvermont
https://sourceware.org/ml/libc-alpha/2015-12/msg00221.html

AMI adds NFC to Aptio V

~ hucktech ~ Leave a comment

AMI has announced support of NFC (near field communication) support for Aptio V, their UEFI firmware solution. Excerpt from press release on the features added to adding to secure NFC:

“With the increasing use of NFC technology, American Megatrends Inc. is now developing NFC support for its flagship Aptio(R) V UEFI BIOS firmware to further security measures. Alongside this support, various features that incorporate NFC technology will be available to users. One of the features, the NFC BIOS Authentication, acts as a replacement to standard password authentication and gives users the ability to authenticate their BIOS using various methods and devices. Authentication can take place using an NFC-enabled cell phone, tablet or identification badge. Administrator and user privileges are based on badge identifications. When an NFC device is detected, the NFC device can be configured to initiate BIOS recovery and specific device booting. Other features will include a single sign on to pass information to the OS, diagnostic and debugging information, and NFC-based Bluetooth pairing.”

http://ami.com/news/press-releases/?PressReleaseID=347&/American%20Megatrends%20Announces%20Development%20of%20NFC%20Support%20for%20Aptio%C2%AE%20V/

I presume this means that Tianocore has no NFC support. (I just realize I’ve never checked…)

US DOD seeking IoT security advice

~ hucktech ~ Leave a comment

Michael Cooney has an article in Network World about US military IoT requirements:

The diversity and capabilities as well as a lack of security found in the  multitude of devices in the Internet of Things world is making people at the US Department of Homeland Security more than a little concerned. This week it put out a call for “novel ideas and technologies to improve situational awareness and security measures for protecting IoT domains, as well as technologies that will help DHS operational and support components gain comprehensive and near continuous knowledge of IoT components and systems that affect their operations and assets.” By using the Internet and its various connection mediums (e.g., Bluetooth, Wi-Fi, serial interface, wireless), any IoT system can be connected to any other device on the Internet. This level of connectivity opens tremendous opportunities for the capabilities of IoT-based systems, but also allows every node, device, data source, communication link, controller and data repository attached to IoT to serve as a security threat and be exposed to security threats. Therefore, any IoT system’s security is limited to the security level of its least secure component, the DHS stated. IoT security efforts are further complicated by IoT’s convergence of physical components and the virtual information flows and connections of IoT. Therefore, DHS stated, in addition to the typical vulnerabilities of IT systems, IoT enabled systems create additional security concerns because IoT domains are:autonomous and control other autonomous systems;highly mobile and/or widely distributed; and are vulnerable to physical and virtual threats. […]

Full article:
http://www.networkworld.com/article/3014438/security/us-homeland-security-wants-heavy-duty-iot-protection.html
https://www.fbo.gov/index?tab=documents&tabmode=form&subtab=core&tabid=dd4493125ecef747d00f71eefbe989e4

Hardware/Firmware security at CCC!

~ hucktech ~ Leave a comment

There are likely other presentations at CCC that’re worth attending, but here are two that you MUST ATTEND, if you’re going to CCC:

Joanna Rutkowska
Towards (reasonably) trustworthy x86 laptops
Can we build trustworthy client systems on x86 hardware? What are the main challenges? What can we do about them, realistically? Is there anything we can? In the first part we will take a look at the security problems we encounter on modern Intel-based x86 systems, specifically on laptops. In the second part we will discuss how most (all?) of these problems could be addressed, with just minimal hardware modifications realizable by laptop OEMs.

Matthew Garrett
Beyond Anti Evil Maid: Making it easier to avoid low-level compromise, and why you’ll still lose
In 2011, Joanna Rutkowska unveiled an easy-to-use tool for mitigating many attacks on system boot chains by using the TPM – the Anti Evil Maid. Unfortunately the implementation was difficult to incorporate into normal system boot in a secure manner – anybody able to observe a user could recreate the secret. This presentation describes a method to allow systems to prove their identity to the user without making it trivial for attackers to mimic a secure boot and extract secrets from the user, and why the state of modern hardware means this may still not be enough. A correctly implemented Trusted Boot solution makes it possible for systems to prove to other systems that they have booted with the expected boot chain. The Anti Evil Maid technique took advantage of this to encrypt a secret with the TPM in such a way that a system whose firmware or bootloader had been compromised would no longer be able to decrypt that secret. Unfortunately, the use of a static secret makes it easier for an attacker to mimic a good boot – as a result, a sufficiently motivated attacker could circumvent Anti Evil Maid and convince the user that a compromised system was in a good state. This presentation describes the use of shared trust between the system and another device, making it significantly more difficult for an attacker to mimic a trusted boot. It includes a description of the implementation of Trusted Boot support in Free operating systems on modern UEFI systems, how this can be tied into sharing trust between multiple devices and the limitations that may still permit state-level actors to compromise these techniques.

https://events.ccc.de/congress/2015/
https://events.ccc.de/congress/2015/Fahrplan/events/7352.html
https://events.ccc.de/congress/2015/Fahrplan/events/7343.html

Nikolaj uploads Zero Nights sources

~ hucktech ~ Leave a comment

Nikolaj has updated his Zero Knights presentation, and added sources and other presentation materials on the Github site:

https://github.com/NikolajSchlej/ZeroNights2015

Nikolaj Schlej to speak on UEFI at ZeroNights

Nikolaj’s ZeroNights presentation available

 

Console OS: be wary

~ hucktech ~ Leave a comment

Console OS is an Intel-based Android-based operating system that is funded via Kickstart. Before you fund/use it, please read this thread, starting with a message from Android-x86’s project leader:

https://lists.01.org/pipermail/android-ia/2015-December/001038.html

Hi all,
[CC this to Android-IA list since the guy continues lying on Android-IA list]

Honestly speaking, I really have no time to check what Christopher Price and his crappy Console OS did recently. But I’m getting more and more private requests to ask me to stop him from stealing the Android-x86 effort. So as the project leader of the Android-x86 project, I think I need to do something. As a background for new comers who haven’t heard the story of Console OS, here is a brief: […]

More info:
https://lists.01.org/pipermail/android-ia/2015-December/thread.html
http://www.android-x86.org/
https://01.org/android-IA
http://consoleos.com/

GOSH! 2016: the Gathering for Open Science Hardware

~ hucktech ~ Leave a comment

On OKFN’s open-science list, Jenny Molloy of OKFN announced “GOSH! 2016”, the Gathering for Open Science Hardware, an event specifically dedicated to open hardware approaches for science, science equipment and education.

What: GOSH! 2016, Gathering for Open Science Hardware
Where: CERN, Switzerland
When: 2-5 March 2016
URL: http://openhardware.science/

On behalf of the organising committee for GOSH! 2016, the Gathering for Open Science Hardware taking place at CERN during 2-5 March 2016, I’d like to tell you a little about it and invite you to apply to join another 50 active users, developers and thinkers in open hardware for science, which we think has the potential to greatly benefit research and education. GOSH! is designed to seed what we hope will be an on-going meeting series and a stronger and more collaborative community in open hardware for science. We want to explore the diversity of existing projects, share best practices and identify needs within the groups engaged in making and using open hardware both within research institutions and beyond. We’ll listen to user stories and developer journeys, host a series of talk and workshops on everything from sharing and licensing to design for manufacture and participate in build workshops to learn from other projects. For more information and to apply via the lightweight form by 19 December 2015. Invitations will be sent out by early January. We are sorry to have such limited space for the event and there will be an opportunity to participate in some sessions remotely and hopefully join us for a larger event in 2017. There is no registration cost and we are currently in the process of sourcing travel sponsorship. We’re not currently in a position to guarantee support but we hope to be able to assist attendees where possible and particularly to fund any participants from the global South. Do let us know on the form if funding assistance would be useful to you.

Organising committee:
Greg Austic, Michigan State University
Adam Wolf, Princeton University
Jenny Molloy, University of Cambridge
Francois Grey, University of Geneva and CERN
Shannon Dosemagen, Public Lab
Aurora Thornhill, Kickstarter
Urs Gaudenz, Gaudi Labs

Home

http://openhardware.science/gosh-2015-schedule/

Facebook’s Big Sur

~ hucktech ~ Leave a comment

https://code.facebook.com/posts/1687861518126048/facebook-to-open-source-ai-hardware-design/

[…]

Big Sur is our newest Open Rack-compatible hardware designed for AI computing at a large scale. In collaboration with partners, we’ve built Big Sur to incorporate eight high-performance GPUs of up to 300 watts each, with the flexibility to configure between multiple PCI-e topologies. Leveraging NVIDIA’s Tesla Accelerated Computing Platform, Big Sur is twice as fast as our previous generation, which means we can train twice as fast and explore networks twice as large. And distributing training across eight GPUs allows us to scale the size and speed of our networks by another factor of two.

In addition to the improved performance, Big Sur is far more versatile and efficient than the off-the-shelf solutions in our previous generation. While many high-performance computing systems require special cooling and other unique infrastructure to operate, we have optimized these new servers for thermal and power efficiency, allowing us to operate them even in our own free-air cooled, Open Compute standard data centers. Big Sur was built with the NVIDIA Tesla M40 in mind but is qualified to support a wide range of PCI-e cards. We also anticipate this will achieve efficiencies in production and manufacturing, meaning we’ll get a lot more computational power per dollar we invest.

Servers can also require maintenance and hefty operational resources, so, like the other hardware in our data centers, Big Sur was designed around operational efficiency and serviceability. We’ve removed the components that don’t get used very much, and components that fail relatively frequently — such as hard drives and DIMMs — can now be removed and replaced in a few seconds. Touch points for technicians are all Pantone 375 C green, the same touch-point color as all of Facebook’s custom data center hardware, which allows technicians to intuitively identify, access and remove parts. No special training or service guide is really needed. Even the motherboard can be removed within a minute, whereas on the original AI hardware platform it would take over an hour. In fact, Big Sur is almost entirely toolless — the CPU heat sinks are the only things you need a screwdriver for.
Collaboration through open source

We plan to open-source Big Sur and will submit the design materials to the Open Compute Project (OCP). Facebook has a culture of support for open source software and hardware, and FAIR has continued that commitment by open-sourcing our code and publishing our discoveries as academic papers freely available from open-access sites. We’re very excited to add hardware designed for AI research and production to our list of contributions to the community.

We want to make it a lot easier for AI researchers to share techniques and technologies. As with all hardware systems that are released into the open, it’s our hope that others will be able to work with us to improve it. We believe that this open collaboration helps foster innovation for future designs, putting us all one step closer to building complex AI systems that bring this kind of innovation to our users and, ultimately, help us build a more open and connected world.

[…]

 

http://www.theregister.co.uk/2015/12/10/facebooks_open_ai_hardware_release/

http://fortune.com/2015/12/10/facebook-ai-big-sur/

http://www.bloomberg.com/news/articles/2015-12-10/facebook-to-publish-designs-for-big-sur-ai-computer-hardware

http://www.opencompute.org/

Dell joins Linux Vendor Firmware Service

~ hucktech ~ Leave a comment

Richard Hughes has a new blog post on Dell joining Linux Vendor Firmware Service (LVFS).

The Linux Vendor Firmware Service Welcomes Dell

Dell has a poll about the service, asking it’s users which models to target next, which Linux distros they use, etc. If you have a Dell system, please be sure to check out the survey.

https://docs.google.com/forms/d/1Hkh13Xh14yUxUciEFqqYiOfPfzR4y5F1xLFgTbs_FU4/viewform?c=0&w=1

http://www.fwupd.org/

So, I guess I need to check fwupd.org before buying a new Linux system, to see if the vendor supports firmware updates or  not. Hmm, I wish fwupd.org had a list of supported OEMs/IHVs: if it does, I missed it, I’ll have to just watch Richard’s blog for new OEM announcements, I guess.

TCG releases/revises many specs

~ hucktech ~ Leave a comment

From the TrustedComputingGroup.org’s newsletter, here’s a list of the most recently published TCG specs/docs. Usually it’s only a few documents, this time it’s a pretty large list:

Guidance for Securing IoT Using TCG Technology
http://www.trustedcomputinggroup.org/resources/guidance_for_securing_iot_using_tcg_technology_reference_document
This document describes typical IoT security use cases and provides guidance for applying TCG technology to those use cases. Because IoT devices vary widely in their cost, usage, and capabilities, there is no one-size-fits-all solution to IoT security. The practical security requirements for different devices and 71 systems will vary. Therefore, this list of solutions should be regarded as a menu from which the implementer can pick the options most suitable for their product or service.

Physical Presence Interface Specification Version 1.30, Revision 00.52
http://www.trustedcomputinggroup.org/resources/tcg_physical_presence_interface_specification
The Physical Presence Interface utilizes the industry-standard Advanced Configuration and Power Interface (ACPI) to provide a communication mechanism between the OS and the BIOS, enabling the OS and the BIOS to cooperate to provide a simple and straightforward platform user experience for administering the TPM without sacrificing security.
 
Errata Version 1.3 for Trusted Platform Module Library Specification, Family “2.0”, Level 00, Revision 01.16
http://www.trustedcomputinggroup.org/files/resource_files/BC34DFDC-1A4B-B294-D057321AEB737B9B/TCG_Errata_Combined_June_16_2015%20Rev%201%203_Final.pdf
This document describes errata and clarifications for the TCG Trusted Platform Module Library Version 2.0 Revision 1.16 as published.

TPM Keys for Platform Identity for TPM 1.2
http://www.trustedcomputinggroup.org/resources/tpm_keys_for_platform_identity_for_tpm_12
This specification addresses ways to incorporate TPM created keys into solutions for device identities. It addresses how the resulting device identities interface with and are represented within an existing public key infrastructure. This specification uses the IEEE Standard for Local and Metropolitan Area Networks, Secure Device Identity (802.1AR) [4] device identity module definition and formatting.

TNC SWID Message and Attributes for IF-M Specification, Version 1.0, Revision 29
http://www.trustedcomputinggroup.org/resources/tnc_swid_messages_and_attributes_for_ifm_specification
The Trusted Network Communications (TNC) Work Group defines an open solution architecture that enables network operators to enforce policies regarding endpoint integrity when granting access to a network infrastructure. Software Identification tags (SWID tags) are XML documents that identify a specific software product.

Storage Interface Interactions Specification. Version 1.04. Revision 1.00
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_interface_interactions_specification
The TCG Storage specifications are intended to provide a comprehensive command architecture for putting storage devices under policy control as determined by the trusted platform host, the capabilities of the storage device to conform with the policies of the trusted platform, and the lifecycle state of the storage device as a trusted peripheral (TPer).

Storage Security Subsystem Class: Enterprise, Version 1.01, Revision 1.00
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class_enterprise_specification
The Storage Workgroup specifications are intended to provide a comprehensive architecture for putting storage devices under policy control as determined by the trusted platform host, the capabilities of the storage device to conform with the policies of the trusted platform, and the lifecycle state of the storage device as a Trusted Peripheral.

Storage Security Subsystem Class: Opal, Version 2.01 Revision 1.00
http://www.trustedcomputinggroup.org/resources/storage_work_group_storage_security_subsystem_class_opal
This specification defines the Opal Security Subsystem Class (SSC). Any SD that claims OPAL SSC compatibility SHALL conform to this specification.

Storage Enterprise Feature Set: PSK Secure Messaging, Version 1.00, Revision 1.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_enterprise_feature_set_psk_secure_messaging
This specification defines PSK Secure Messaging for the Enterprise Security Subsystem Class (SSC). Any Storage Device that claims Enterprise SSC PSK Secure Messaging compatibility SHALL conform to this specification.

Storage Opal SSC Feature Set: PSK Secure Messaging, Version 1.00, Revision 1.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_ssc_feature_set_psk_secure_messaging
This specification defines PSK Secure Messaging for the Opal Security Subsystem Class (SSC). Any Storage Device that claims Opal SSC PSK Secure Messaging compatibility SHALL conform to this specification.

Storage Feature Set: Block SID Authentication, Version 1.00 Final, Revision 1.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_feature_set_block_sid_authentication_specification
This specification defines the Block SID Authentication Feature. Any Storage Device that claims Block SID Authentication compatibility SHALL conform to this specification.

Storage Opal SSC Feature Set: PSID Version 1.00, Revision 1.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_feature_set__psid
This specification defines the PSID Feature Set for the Opal Security Subsystem Class (SSC). Any Storage Device that claims Opal SSC PSID Feature Set compatibility SHALL conform to this specification.

Storage Security Subsystem Class: Pyrite, Version 1.00 Final, Revision 1.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_security_subsystem_class_pyrite
This specification defines the Pyrite Security Subsystem Class (SSC). Any SD that claims Pyrite SSC compatibility SHALL conform to this specification. The intended audience for this specification is both trusted Storage Device manufacturers and developers that want to use these Storage Devices in their systems.

Storage Opal SSC Feature Set: Single User Mode Specification, Version 1.00, Revision 2.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_opal_ssc_feature_set_single_user_mode
This specification defines the Single User Mode for the Opal Security Subsystem Class (SSC). Any Storage Device that claims Opal SSC Single User Mode compatibility SHALL conform to this specification.

Storage Security Subsystem Class: Opalite Version 1.00 Revision 1.00
http://www.trustedcomputinggroup.org/resources/tcg_storage_security_subsystem_class_opalite
This specification defines the Opalite Security Subsystem Class (SSC). Any SD that claims Opalite SSC compatibility SHALL conform to this specification.

TPM-tools for TPM 2.0

~ hucktech ~ Leave a comment

I was just looking on Intel’s 01.org to see what’s new, or some older things I’ve not yet noticed.

I just noticed there are two projects with updated TPM 2.0 support:

TPM2-0-TSS:

TPM (Trusted Platform Module) 2.0 Software Stack (TSS). This stack consists of the following layers from top to bottom:
 * Feature API (FAPI), see specification 0.12, (published but still in progress and unimplemented)
 *  Enhanced System API (ESAPI), (specification in progress and unimplemented)
 *  System API (SAPI), see 1.0 specification, (public, 0.97 implementation complete)
 *  TPM Command Transmission Interface (TCTI), used by SAPI to communicate with next lower layer (either the TAB/RM or TPM 2.0 device driver), see SAPI specification
 *  Trusted Access Broker/Resource Manager (TAB/RM), see 0.91 specification, (public, implementation complete)

https://github.com/01org/TPM2.0-TSS

TPM2-0-tools:

This site contains the code for the TPM (Trusted Platform Module) 2.0 tools based on TPM2.0-TSS. Below is the name list of the implemented tools:
Subset 1: NV tools: tpm2_nvdefine tpm2_nvrelease tpm2_nvread tpm2_nvwrite tpm2_nvlist
Subset 2: Attestation tools: tpm2_takeownership tpm2_getpubek tpm2_getpubak tpm2_akparse tpm2_makecredential tpm2_activatecredential tpm2_listpcrs tpm2_quote
Subset 3: Key management tools: tpm2_createprimary tpm2_create tpm2_evictcontrol tpm2_load tpm2_loadexternal
Subset 4: Encryption tools: tpm2_encryptdecrypt tpm2_rsaencrypt tpm2_rsadecrypt tpm2_unseal
Subset 5: Signing tools:  tpm2_sign tpm2_verifysignature tpm2_certify
Subset 6: utilities:  tpm2_getrandom tpm2_hash tpm2_hmac tpm2_readpublic

https://github.com/01org/tpm2.0-tools

Qubes OS 3.1 rc1 released, with UEFI support

~ hucktech ~ Leave a comment

New features since 3.0:
 * Management Stack based of Salt Stack in dom0
 * Out of the box Whonix setup
 * UEFI support
 * LIVE edition (still alpha, not part of R3.1-rc1)
 * Updated GPU drivers in dom0
 * Colorful window application icons (instead of just colorful lock icon)
 * PV Grub support (documentation)
 * Out of the box USB VM setup, including handling USB mouse
 * Xen upgraded to 4.6, for better hardware support (especially Skylake platform)
 * Improve updates proxy flexibility – especially repositories served over HTTPS

https://www.qubes-os.org/news/2015/12/08/qubes-OS-3-1-rc1-has-been-released/

https://www.qubes-os.org/doc/releases/3.1/release-notes/

 

Open Source Hardware for Scientists

~ hucktech ~ Leave a comment

Joshua M. Pearce has an article on Scientific American’s blog, talking about making lab hardware using Open Source Hardware model.

Science for All: How to Make Free, Open Source Laboratory Hardware

[…] If you are a working scientist, it is in your best interest to share the designs for your hardware. Consider for example the humble lab jack, which is used to move heavy or bulky equipment small distances up or down (we use one in my lab to move solar photovoltaic materials into a light path, for example). I received a shocking $950 quote for one. Although much less expensive lab jacks are available, we wanted a customizable lab jack. We designed one for less than $5 and shared it on the web. Then the fun began. A Finnish maker recommended an improved assembly that made it better and since then over 3,700 others have downloaded the designs. Next, a French scientist shared a better design that reduces the number of non-3-D printed parts. Most recently a Seattle-based company posted a 100% 3-D printable version. It even prints assembled! Now anytime I need a lab jack I can print one out of recyclebot-made plastic filament for a few pennies. […]

Full article:
http://blogs.scientificamerican.com/guest-blog/science-for-all-how-to-make-free-open-source-laboratory-hardware/

PS: Next year’s Open Hardware Summit will be in Portland Oregon in October 2016-timeframe:

EDK-II Build Data Viewer

~ hucktech ~ Leave a comment

William Leara has a new blog post on Intel’s EDK-II Build Data Viewer tool; it is a detailed post with multiple screenshots and images:

http://www.basicinputoutput.com/2015/12/the-edkii-build-data-viewer.html

Wow, I missed this tool from Intel when it first came out, so I’m very glad for this post! Note this source project is hosted on 01.org, not tianocore.org.

Unfortunately, it sounds like the tool may be difficult to use:

“The EDKII Build Data Viewer is beautifully designed.  The documentation is top notch.  It provides a wealth of information in one place that would be time-consuming to discover independently.  Unfortunately I was not able to get it to run on the production BIOS source trees I have available to me, but hopefully you have better luck.”

If anyone gets it working, please leave a comment with a pointer to more info.

https://github.com/01org/edkiibuilddataviewer

Brian on Secure Boot -vs- Nemesis

~ hucktech ~ Leave a comment

Brian Richardson of Intel wrote a new blog on the recent Nemesis malware:

(Nemesis targets BIOS-centric MBR not UEFI-centric GPT partititions.)

http://blogs.intel.com/evangelists/2015/12/08/nemesis-meet-uefi-secure-boot/

new Linux-IMA patchset closes multiple measurement/appraisal gaps

~ hucktech ~ Leave a comment

Mimi Zohar and Dmitry Kasatkin have created a new patchset for Linux IMA which:

“closes a number of measurement/appraisal gaps by defining a generic function named ima_read_and_process_file() for measuring and appraising files read by the kernel (eg. kexec image and initramfs, firmware, IMA policy). To differentiate between callers of ima_read_and_process_file() in the IMA policy, a new enumeration is defined named ima_read_hooks, which initially includes KEXEC_CHECK, INITRAMFS_CHECK, FIRMWARE_CHECK, and POLICY_CHECK.

separate ‘security.ima’ reading functionality from collect
load policy using path
update appraise flags after policy update completes
measure and appraise kexec image and initramfs
measure and appraise firmware (improvement)
measure and appraise the IMA policy itself
require signed IMA policy

 Documentation/ABI/testing/ima_policy      |  2 +-
 drivers/base/firmware_class.c             | 15 +++++–
 include/linux/ima.h                       | 12 +++++
 kernel/kexec_file.c                       | 28 +++++++—–
 security/integrity/digsig.c               |  2 +-
 security/integrity/iint.c                 | 24 +++++++—
 security/integrity/ima/ima.h              | 24 +++++—–
 security/integrity/ima/ima_api.c          | 51 +++++++++++++++——
 security/integrity/ima/ima_appraise.c     | 40 +++++++++++——
 security/integrity/ima/ima_crypto.c       | 56 ++++++++++++++++——–
 security/integrity/ima/ima_fs.c           | 45 ++++++++++++++++++-
 security/integrity/ima/ima_init.c         |  2 +-
 security/integrity/ima/ima_main.c         | 55 ++++++++++++++++++—–
 security/integrity/ima/ima_policy.c       | 73 ++++++++++++++++++++++++——-
 security/integrity/ima/ima_template.c     |  2 –
 security/integrity/ima/ima_template_lib.c |  3 +-
 security/integrity/integrity.h            | 14 +++—
 17 files changed, 329 insertions(+), 119 deletions(-)

More information:
https://lists.sourceforge.net/lists/listinfo/linux-ima-devel