well,
it appears that the "conspiracy theory" of someone shorting tech stocks has already happened. the CEO of Intel dumped a huge load of stock last november. Now, it is likely that it was for another reason, but the timing seems rather suspect. btw, said CEO is now under review by the SEC and may be facing charges of insider trading.
-eric
from the central offices of the technomage Guild, News Dept.
On Jan 8, 2018, at 9:29 PM, David Schwartz wrote:
> I haven’t done any in-depth research on this, but from what I have read, I cannot really see how anything running in a virtualized or interpreted environment, or something that doesn’t have direct access to the physical machine, would be a potential threat.
>
> The 286 chip had a "protected mode” built into it. IBM and Microsoft spent a huge amount of money writing an OS that was designed to run in protected mode. But it turned out that one of the chip designers at Intel decided to save a few bytes of microcode and created a situation where the processing of the interrupt vector that pushed the current IP onto the stack was not an “atomic” operation — it could be interrupted. And this affected context switches into protected mode.
>
> I was working at Intel at the time and there was quite a bit of discussion about this, mostly a lot of jokes about the probability of lightning striking the same person twice on the same golf course on a cloudless day. That is to say, the statistical likelihood of that happening during “normal” operation was absurdly low.
>
> Needless to day, a protected OS was never released for the 286. But while they were busy fixing this bit of microcode to make the 386 work properly, there was enough pressure from customers that they added a new memory model option that disabled the “segmented memory model” that the 286 used and allowed it to run in a “virtual” mode that flattened the entire address space.
>
> They still had a couple of protected areas that were carried over from the 286 (the GOT and GDT, amongh others) that could only be accessed when the chip was put into a special mode that only the OS kernal was supposed to do.
>
> But there were rumors that there were other ways of triggering faults on the chip to gain access to some of the protected memory areas. These areas were protected by virtue of the fact that they required a base segment register to be loaded that pointed to an area of memory that was outside of the normal memory space. To access them, you generally had to put the chip into what amounts to “admin” mode (I forget what it’s called), load the registered and trigger a fault (or sw interrupt). As I recall, this required some assistance from the memory chip interfaces because they used an address bit that wasn’t part of the regular 32-bit address space.
>
> (Motorola advocates argued that their chips didn’t require this special chip between the CPU and system RAM, but it was simply a dynamic RAM controller. I suspect it took on additional security roles over time because it WAS independent of the CPU.)
>
> During normal operation, it’s virtually impossible to trigger these modes. It used to be that you had to put the chip into “single-user mode” briefly, just like in a Unix environment when you need to perform certain low-level OS operations. (Windows doesn’t do that, which is why you have to reboot the damn thing every time you install a new device driver, for instance.)
>
> It would be necessary to overwrite some kernal code that executes when the chip is in this “admin” mode, and that code would have to execute some protected-mode instructions in a very specific order. Most other things are locked-out while that’s going on, so it’s not a mode that’s usually enabled for very long.
>
> They could have changed things since then, but from what I’ve read this particular “hairline fracture" has been around forever, and isn’t even rooted in a specific CPU or CPU family, but possibly due to interactions between the CPU and (external) memory controllers.
>
> The moral of the story is … if this is something that java or javascript or anything running in a web browser can trigger, then there’s absolutely no way to protect any aspect of the hardware whatsoever.
>
> Said another way, it would allow the web browser to install a device driver in Windows and activate it without having to reboot the machine. I for one would welcome a standalone app that would do that! Not so much something that runs in a web browser, tho.
>
> People would be patching the kernel, switching into protected mode, fiddling within things any time they like, reprogramming the hardware … I mean. there would be no limits to what could be done by code running anywhere.
>
> In 30 years we haven’t seen any evidence that this is the case, even though this has apparently been around forever.
>
> Have there even been any reports of any code “in the wild” triggering this exploit from a web browser?
>
> The articles I’ve seen only said it was discovered “in a lab” and they were able to trigger it “in the lab”.
>
> I’m not much of a conspiracy theorist, but I’m far more inclined to think this is something that the engineers who work at chip and hardware vendors have known about for decades, only never talked about, and somebody with a lot of money caught wind of it and decided to use it to win his own lottery by shorting a bunch of tech stocks before announcing this “shocking hack” to the world.
>
> -David Schwartz
>
>
>
>> On Jan 8, 2018, at 8:09 PM, techlists@phpcoderusa.com wrote:
>>
>> Hi,
>>
>> I'm looking for more info or ideas on how one might protect them self given Meltdown and Spectre.
>>
>> Now that it has come to light that computer memory is not completely segregated or kept private by the CPU hardware... a failure in design allowing a hacker access to even the CPU Kernel memory. This is catastrophic.
>>
>> I'm reading the initial solution is for the O/S manufactures to patch their Kernel to secure the memory at its boundaries. In and of itself this seems to be a weak approach, however probably the only one at this point.
>>
>> I am reading that the real solution is a new bread of CPU that does not have this vulnerability. It would seem even modifying the existing CPUs and manufacturing them would take months if not a year or so. In the meantime we have to survive with hardware patched with software.
>>
>> I read that desktops are the most vulnerable. Maybe that should be any devise that runs a browser. The browser is the point of failure. Introduce some rogue JavaScript and your memory is compromised.
>>
>> This article says one should enable site isolation using Chrome.
>>
>> At this point my preventative steps are:
>>
>> 1) flush all browsers of any usernames, passwords and history.
>>
>> 2) Only run the latest version of Chrome and only Chrome.
>>
>> 3) Configure Chrome to run in isolation mode.
>>
>> Anyone have any other thoughts?
>>
>> Thank you in advance.
>>
>> Keith
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)