SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
SoylentNews
Joanna Rutkowska's blog points to recent paper on a survey of the various problems and attacks presented against the x86 platform over the last 10 years. The paper does not present new exploits but does cover: the BIOS (UEFI) and booting; peripherals; the Intel Management Engine; and several other aspects of x86 insecurity. Some of the problems appear insurmountable as described.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
The last time I saw him he was walking down Lover's Lane holding his own hand.
-- Fred Allen
(Score: 3, Interesting) by Techwolf on Friday October 30 2015, @03:53PM
This is one reason i am happy to see ARM taking off like it is. Best part is anyone can make them. No Intle monipoly.
Slightly off-topic, but how did the horriable memory mapping come about? ROM shoulda started at 0x00 and RAM after that. Then RAM coulda been expanded beyound current bit with without having to hack it in. 0 Is allways 0, even 00000000.
Example:
ROM 0000 to 0100 increased to xx bits, 00000000 to 0000100.
RAM 0100 to ffff increased to xx bits, RAM 00000100 to fffffffff.
(Score: 4, Informative) by NCommander on Friday October 30 2015, @05:38PM
As someone who worked with ARM, trust me, it's not better from a security perspective. Its essentially the same as x86 minus the backward compatibility.
ARM32 and AArch64 (ARM64) both come with trustzone built onto the die which allows you to run a hypervisor transparently to the main operating system. On AArch64, your processor comes out of reset in EL3 , and can thus hide things from lower privilege levels. Furthermore, at least on AArch64, ACPI has become a standard, which requires the ACPI runtime baked into the kernel (which must run unsandboxed and capable of running any command itlikes)
Still always moving
(Score: 2) by LoRdTAW on Friday October 30 2015, @07:06PM
Thanks to Microsoft's craptastic Windows 8 and 10. Otherwise there would be no need to port such a broken system management setup to ARM.
(Score: 2) by NCommander on Friday October 30 2015, @11:40PM
There were technical justifications for why ACPI won over flattened device tree, specifically because FDT is a descriptive only environment. A properly coded ACPI table allows a LOT of hardware to just work without individually written drives. Most fan systems are controlled by a I2C chip. Withotu ACPI, you'd need to know where the I2C chip is on the system bus, a specific driver for said chip, and then a driver for fan control. With ACPI, you can define the standard fan control methods and it "just works".
I'm not saying ACPI is genius, but if you're dealing with a vendor who actually tests their ACPI implementation against something that isn't just Windows, and follows the spec, you'd be amazed on how Linux can "just work" for the most part. A lot of the enablement of Linux for x86 laptops on an OEM side is mostly fixing the ACPI tables, and then making sure the right firmware is cooked in.
Still always moving
(Score: 4, Interesting) by novak on Friday October 30 2015, @08:43PM
The only mitigation to ARM's many woes is that at least we have multiple vendors producing them and the BIOS is sometimes open. x86 is rapidly becoming intel only, and nearly every x86 board ever made runs proprietary BIOS and firmware.
Going to another architecture- even one not much better- could still be a massive step in the right direction as the amount of devices running open firmware skyrockets. Allowing modification of firmware and BIOS at least helps clear up glaring backdoors like IPMI and badUSB which have been standing wide open for years.
novak
(Score: 2) by NCommander on Friday October 30 2015, @11:42PM
ARM mostly uses the same UEFI base (TianoCore) as x86 for anything that isn't embedded.
I'm not kidding when I can say with a straight face it was an improvement in increasing the "just works" factor over u-boot. Unfortunately, TianoCore isn't GPL, so its not required that vendors post their firmware source.
Still always moving