New Intel processor vulnerability

[Jan Panteltje]

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

 

[boB]

On Tue, 14 May 2019 19:21:55 GMT, Jan Panteltje
<pNaOnStPeAlMtje@yahoo.com> wrote:

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

Surprised ?

 

[Jan Panteltje]

On a sunny day (Wed, 15 May 2019 13:45:08 +1000) it happened Sylvia Else
<sylvia@email.invalid> wrote in <gk1ga6F4rouU1@mid.individual.net>:

On 15/05/2019 5:21 am, Jan Panteltje wrote:
New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD


These things are going to keep cropping up until its realised that you
cannot make them safe as long as any kind of cache (widely defined)
filled in one security context is used in another security context.
They'll either have to do a complete flush when changing security
contexts, including from supervisor to user, or have a separate cache
per context. In practice a combination of the two would likely be needed.

Consumer level gear could probably manage with just three caches
(supervisor, user, and sandbox) without getting too bogged down. Cloud
servers would need rather mode.

An alternative might, in some situations, be to deprive user code of the
timing resources it needs to exploit this kind of vulnerability, but
people have a habit of finding ways round such restrictions.

Sylvia.

Yes that is logical,
and I am sure somebody over at Intel knows that.
But there is the need for more speed
and maybe input from Big Brother to keep things that way
so they can check on what people are doing.

Bit less bloatware would not require so much processor power.

 

[Jan Panteltje]

On a sunny day (Tue, 14 May 2019 15:00:41 -0700) it happened boB
<boB@K7IQ.com> wrote in <sjemde96mh43p6p2fcn86opngkgss3aill@4ax.com>:

On Tue, 14 May 2019 19:21:55 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

Surprised ?

Yes, though they would have fixed their stuff by now.

 

[Sylvia Else]

On 15/05/2019 5:21 am, Jan Panteltje wrote:

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

These things are going to keep cropping up until its realised that you
cannot make them safe as long as any kind of cache (widely defined)
filled in one security context is used in another security context.
They'll either have to do a complete flush when changing security
contexts, including from supervisor to user, or have a separate cache
per context. In practice a combination of the two would likely be needed.

Consumer level gear could probably manage with just three caches
(supervisor, user, and sandbox) without getting too bogged down. Cloud
servers would need rather mode.

An alternative might, in some situations, be to deprive user code of the
timing resources it needs to exploit this kind of vulnerability, but
people have a habit of finding ways round such restrictions.

Sylvia.

 

Jan Panteltje <pNaOnStPeAlMtje@yahoo.com> wrote in
news:qbf4gt$1ab$1@dont-email.me:

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-
bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

I think this week's round of updates included an Intel microcode
update. It was likelt to address this addressing issue.

It has hit every machine I have, and I even saw Linux updates
yesterday that included Intel package updates.

 

Sylvia Else <sylvia@email.invalid> wrote in
news:gk1ga6F4rouU1@mid.individual.net:

On 15/05/2019 5:21 am, Jan Panteltje wrote:
New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-
executio
n-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD


These things are going to keep cropping up until its realised that
you cannot make them safe as long as any kind of cache (widely
defined) filled in one security context is used in another
security context. They'll either have to do a complete flush when
changing security contexts, including from supervisor to user, or
have a separate cache per context. In practice a combination of
the two would likely be needed.

Consumer level gear could probably manage with just three caches
(supervisor, user, and sandbox) without getting too bogged down.
Cloud servers would need rather mode.

An alternative might, in some situations, be to deprive user code
of the timing resources it needs to exploit this kind of
vulnerability, but people have a habit of finding ways round such
restrictions.

Sylvia.

So does Intel, and I am sure they will end up prevailing again.

You will not see me jumping onto the AMD bandwagon any time soon.

My xeon and quadro do 3D CAD just fine.

Anyone stop to think that AMD might be hunting for these
'vulnerabilities'? If someone hunted, they could likely find one in
an AMD CPU as well.

It is like the virus on windows but no linux thing.

IF Linux were more popular, it would have more time spent on
invading it. Yes, I know it is inherently a more secure OS. That
is not my point... or maybe it is exactly my point.

I am staying with Intel and their decades of experience.

 

[Rick C]

On Wednesday, May 15, 2019 at 12:32:17 AM UTC-4, Jan Panteltje wrote:

On a sunny day (Wed, 15 May 2019 13:45:08 +1000) it happened Sylvia Else
sylvia@email.invalid> wrote in <gk1ga6F4rouU1@mid.individual.net>:

On 15/05/2019 5:21 am, Jan Panteltje wrote:
New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD


These things are going to keep cropping up until its realised that you
cannot make them safe as long as any kind of cache (widely defined)
filled in one security context is used in another security context.
They'll either have to do a complete flush when changing security
contexts, including from supervisor to user, or have a separate cache
per context. In practice a combination of the two would likely be needed.

Consumer level gear could probably manage with just three caches
(supervisor, user, and sandbox) without getting too bogged down. Cloud
servers would need rather mode.

An alternative might, in some situations, be to deprive user code of the
timing resources it needs to exploit this kind of vulnerability, but
people have a habit of finding ways round such restrictions.

Sylvia.

Yes that is logical,
and I am sure somebody over at Intel knows that.
But there is the need for more speed
and maybe input from Big Brother to keep things that way
so they can check on what people are doing.

Bit less bloatware would not require so much processor power.

Write to Trump. I bet he will support a wall to keep out bloatware.

--

Rick C.

- Get 5,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[boB]

On Wed, 15 May 2019 04:24:15 GMT, Jan Panteltje
<pNaOnStPeAlMtje@yahoo.com> wrote:

On a sunny day (Tue, 14 May 2019 15:00:41 -0700) it happened boB
boB@K7IQ.com> wrote in <sjemde96mh43p6p2fcn86opngkgss3aill@4ax.com>:

On Tue, 14 May 2019 19:21:55 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

Surprised ?

Yes, though they would have fixed their stuff by now.

Well, after all it IS Intel.

They have been known to know about bugs and not say anything until
someone called them on it.... At least in the 1970s and 1980s.
Maybe this is the same kind of thing ? I would hope they would have
gotten better at that kind of thing. Intel doesn't hand out
documentation anymore like they used to soI'm sure it's just their big
users that worry about that stuff nowadays and most likely under some
NDAs on these types of holes so peons like me won't know about it
until it's made public.

 

[Robert Baer]

boB wrote:

On Wed, 15 May 2019 04:24:15 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:

On a sunny day (Tue, 14 May 2019 15:00:41 -0700) it happened boB
boB@K7IQ.com> wrote in <sjemde96mh43p6p2fcn86opngkgss3aill@4ax.com>:

On Tue, 14 May 2019 19:21:55 GMT, Jan Panteltje
pNaOnStPeAlMtje@yahoo.com> wrote:

New Intel processor vulnerability
https://arstechnica.com/gadgets/2019/05/new-speculative-execution-bug-leaks-data-from-intel-chips-internal-buffers/

At least this PC is safe with AMD

Surprised ?

Yes, though they would have fixed their stuff by now.


Well, after all it IS Intel.

They have been known to know about bugs and not say anything until
someone called them on it.... At least in the 1970s and 1980s.
Maybe this is the same kind of thing ? I would hope they would have
gotten better at that kind of thing. Intel doesn't hand out
documentation anymore like they used to soI'm sure it's just their big
users that worry about that stuff nowadays and most likely under some
NDAs on these types of holes so peons like me won't know about it
until it's made public.


"peon" = = peed on

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus