Re: Intel design flaw

[Zenaan Harkness]

On Thu, Jan 04, 2018 at 10:03:00AM -0800, Ryan Carboni wrote:
> https://lkml.org/lkml/2018/1/3/797
> 
> A *competent* CPU engineer would fix this by making sure speculation
> > doesn't happen across protection domains. Maybe even a L1 I$ that is
> > keyed by CPL.
> 
> https://news.ycombinator.com/item?id=10518480
> 
> Aye, too many people have this defeatist attitude that since perfect
> > security will never be possible, therefore the only valid solution is
> > reactive security (bug-patch cycles). Patch dependence is considered too
> > entrenched for making some changes like replacing ambient authority with
> > capabilities, using failure-oblivious computing [1] to redirect invalid
> > reads and writes, using separation kernels, information flow control,
> > proper MLS [2], program shepherding for origin and control flow monitoring
> > [3] and general fault tolerance/self-healing [4].

> > I used to look up to Linus Torvalds as many did, but am increasingly
> > beginning to see him as a threat to the advancement of the industry with
> > his faux pragmatism that has led him to speak out against everything from
> > security to microkernels and kernel debuggers.

And debugged copyleft licenses.

But, oh he's pragmatic alright - pragmatic is of course contextual,
and Linus' (and the majority of the subsystem maintainers) pragmatism
puts performance above most other things - although it could also be
reasonably argued that functionality is put over most other
considerations - lack of performance is of course a "lack of
functionality", and bugs are another type of lack of functionality;

this is a very utilitarian (i.e. “pragmatic”) approach, but to the
detriment of security, and also to the detriment of moral principles
- that bug in the GPL 2 which effectively allowed for the proprietary
appropriation of $2 trillian of values from the free/libre software
ecosystem over the last two decades (into Googoyle, Twatter,
Facesluts, Amazon and many other centralisations and hoarding of code
in the pursuit of money, co-opting authority and dashing rights and
freedoms on the sociopathic alter of "shareholder profit imperative".

Well, sheeeiiit. What do we expect when the most prominent one,
Linus, proclaims in every interview ever that freedom and liberty are
political and so "I don't want to get involved in that shit, just
gibs me dat code already, it's useful and this "free software"
development model makes lots of really cool code and gibs me lots of
shiny things".

Except $2 Trillian dollars of shiny things value is locked up in
corporate structures owned and controlled by (((certain individuals
with an extremist ideology, authoritarian bent and tribal
consciousness whom we are getting somewhat familiar with these
days))).

And freedom is looking more like 1984 and The Ministry of Truth every
week.

 Yeah, like, thanks, Linus - ’cause who needs freedom,
  right?




> > [1] https://www.doc.ic.ac.uk/~cristic/papers/fo-osdi-04.pdf
> > [2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52
> > [3] https://www.usenix.org/legacy/events/sec02/full_papers/kiria...
> > [4] https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-se...

Re: Intel design flaw

[John Young]

Security is like sin, without flaws no need for it. And like religion 
it's forever fallible, requiring constant fixes and upgrades. Last 
thing security experts want is infallibility. Do security experts 
build in flaws? Of course. No wonder insiders betray bosses, set up own shop.

Intel design flaw

[Ryan Carboni]

P.S. forgot this.
https://lobste.rs/s/mij1sz/some_security_people_are_f_cking_morons#c_2b4mfh

Re: Intel design flaw

[Georgi Guninski]

On Wed, Jan 03, 2018 at 06:42:43AM -0500, John Newman wrote:
> I think they might go bankrupt ;)
>
Won't cry much in this case.

theregister claims javascript in a web browser can exploit it, is this
true? I think js can't read memory in the browser process, let alone
kernel stuff.
 

Intel design flaw

[Ryan Carboni]

Fortunately Intel's IA-64 was designed properly, with coarse
multithreading, and explicit simultaneous instruction dispatch.

There is also enough demand for IA-64 for them to keep releasing new
versions.

It is also fortunate that Project Zero doesn't release exploits for the
predominant processor within thirty days, the same goes for the predominant
web browser.

I wonder what went wrong with processor design. Pentium 4 had about a
hundred million transistors. Now they have roughly thirty times that. Given
the amount of time spent on switching contexts and loading data, instead of
improving artificial benchmarks, reducing idle time would've been better by
allowing each core to hold thirty threads.

Although carryless multiplication would have been useful right when AES was
adopted

Extrastatecraft is a good read.

Re: Intel design flaw

[juan]

On Wed, 03 Jan 2018 06:42:43 -0500
John Newman  wrote:

> 
> 
> On January 3, 2018 5:31:39 AM EST, Georgi Guninski
>  wrote:
> >On Wed, Jan 03, 2018 at 08:48:12AM +, jim bell wrote:
> >> For some reason, I'm reminded of the 486 math processor  screwup of
> >1992 (?).  As I vaguely recall, the math coprocessor might have
> >errors in the fourth digit of significance.  Intel offered to
> >replace the affected chips.
> >>
> >
> >I think it is the Pentium FDIV bug. IIRC only the server CPU was
> >replaced in the whole office, don't remember why.
> >
> > From TFA: microcode can't fix it, lol. AMD is not affected.
> > Shouldn't
> >Intel do recall again?
> > 
> 
> I think they might go bankrupt ;)


haha I wish. If people tried to sue intel, the US govt would
throw the plaintiffs in jail.

Oh, and here's another Pretty Good One 

https://arxiv.org/pdf/1710.00551

looks like all RAM is fucked hahaha











> 
> And think of all the work for sysadmins swapping CPUs &
> swapping systems... I think we are going to be stuck with 
> OS level fixes that are potentially very bad for performance.
> People are already grumbling about the potential impact on
> AWS & other cloud providers... Speculation about a 30%
> performance hit?!
> 
> 
> https://www.reddit.com/r/technology/comments/7npcgu/kernel_memory_leaking_intel_processor_design_flaw/
> 
> 

Re: Intel design flaw

[jim bell]

 On Wednesday, January 3, 2018, 2:31:44 AM PST, Georgi Guninski 
 wrote:
 
 
 On Wed, Jan 03, 2018 at 08:48:12AM +, jim bell wrote:
> For some reason, I'm reminded of the 486 math processor  screwup of 1992 (?). 
>  As I vaguely recall, the math coprocessor might have errors in the fourth 
> digit of significance.  Intel offered to replace the affected chips.

>I think it is the Pentium FDIV bug. IIRC only the server CPU was
replaced in the whole office, don't remember why.


While doing a Google search, I saw reference to the Pentium problems, but there 
definitely was a 486 problem too.  In fact, it came with a joke:  The drug 
"RU486" had been relatively recently been released, and the joke was that the 
486 "prevented you from multiplying". 

The corrected, replacement CPU was given a double-sigma after the 486, although 
I just found that a similar double-sigma was used for the replacement for a 386 
bug as well.   

>From TFA: microcode can't fix it, lol. AMD is not affected. Shouldn't
Intel do recall again?

Presumably, yes, especially due to the performance hit.  I'm satisfied with 
AMD, but the people who insist on Intel processors claim that it's worth the 
extra money.  But that argument gets destroyed if "fixing" the problem produces 
more than a small hit.

            Jim Bell
 


 
  

Re: Intel design flaw

[John Newman]

On January 3, 2018 5:31:39 AM EST, Georgi Guninski  
wrote:
>On Wed, Jan 03, 2018 at 08:48:12AM +, jim bell wrote:
>> For some reason, I'm reminded of the 486 math processor  screwup of
>1992 (?).  As I vaguely recall, the math coprocessor might have errors
>in the fourth digit of significance.  Intel offered to replace the
>affected chips.
>>
>
>I think it is the Pentium FDIV bug. IIRC only the server CPU was
>replaced in the whole office, don't remember why.
>
> From TFA: microcode can't fix it, lol. AMD is not affected. Shouldn't
>Intel do recall again?
> 

I think they might go bankrupt ;)

And think of all the work for sysadmins swapping CPUs &
swapping systems... I think we are going to be stuck with 
OS level fixes that are potentially very bad for performance.
People are already grumbling about the potential impact on
AWS & other cloud providers... Speculation about a 30%
performance hit?!


https://www.reddit.com/r/technology/comments/7npcgu/kernel_memory_leaking_intel_processor_design_flaw/




signature.asc
Description: PGP signature

Re: Intel design flaw

[Georgi Guninski]

On Wed, Jan 03, 2018 at 08:48:12AM +, jim bell wrote:
> For some reason, I'm reminded of the 486 math processor  screwup of 1992 (?). 
>  As I vaguely recall, the math coprocessor might have errors in the fourth 
> digit of significance.  Intel offered to replace the affected chips.
>

I think it is the Pentium FDIV bug. IIRC only the server CPU was
replaced in the whole office, don't remember why.

 From TFA: microcode can't fix it, lol. AMD is not affected. Shouldn't
Intel do recall again?
 

Re: Intel design flaw

[jim bell]

 

On Wednesday, January 3, 2018, 12:34:55 AM PST, John Newman 
 wrote:  
 >Looks like Intel has done it again!

>Who needs uid == root when you can just run on an Intel proc
and take a peek at protected memory anytime you like, cuz
the silicon's fucked?


>http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/


>OS VM layers are being rapidly rewritten, performance hits 
will accrue, and who knows what else is broke...



For some reason, I'm reminded of the 486 math processor  screwup of 1992 (?).  
As I vaguely recall, the math coprocessor might have errors in the fourth digit 
of significance.  Intel offered to replace the affected chips.

                     Jim Bell
  

Intel design flaw

[John Newman]

Looks like Intel has done it again!

Who needs uid == root when you can just run on an Intel proc
and take a peek at protected memory anytime you like, cuz
the silicon's fucked?


http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/


OS VM layers are being rapidly rewritten, performance hits 
will accrue, and who knows what else is broke...




signature.asc
Description: PGP signature