On Fri, Dec 9, 2016 at 4:53 AM, Roman Mamedov wrote:
> option available today, and you don't have to go back to Pentium 200 to avoid
Using such a relic as a scrub firewall might protect you from magic packets
launched by your adversaries towards one of those listening
On Fri, 9 Dec 2016 04:17:49 -0500
grarpamp wrote:
> >> Intel ME/AMT concerns me too
>
> > AMD Family 15h itself is safe.
>
> No one has any proof of that for any modern cpu from any
> maker, featureset irrelavant.
Sure, to clarify what's meant here is "it does not
-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of
grarpamp
Sent: Friday, December 09, 2016 11:18 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] Exploiting firmware
>>> Intel ME/AMT concerns me too
>>
>> Intel ME/AMT concerns me too
> AMD Family 15h itself is safe.
No one has any proof of that for any modern cpu from any
maker, featureset irrelavant. They all accept microcode updates,
which btw are all encrypted closed binary blobs. And the
chips themselves are fully closed source containing
On Wed, 7 Dec 2016 22:50:39 +
Alex Haydock wrote:
> Intel ME/AMT concerns me too, especially how unavoidable it seems to be
> on modern CPUs (AMD is no escape, as they have an equivalent in the form
> of their "Platform Security Processor").
On AMD that's been
Op 07-12-16 om 23:50 schreef Alex Haydock:
AMD is no escape, as they have an equivalent in the form
of their "Platform Security Processor"
I believe[1] the Athlon 5370 that AMD released this year is without PSP.
Suits small form factors and has good performance for the mere 25 Watt
that it
On 07/12/16 23:15, diffusae wrote
> I am totally agree with you.
>
> One alternative would be to use coreboot on your machine. If you are
> good, than you will put your kernel into the flash chip and make it
> write protected.
As far as I know, Coreboot is merely an open source BIOS replacement
As long as CPU hardware is closed source, perfect privacy does not exist, full
stop. Conspiracy theories are futile, the probability of microcode backdoor is
1. So there is no need to "worry" about hardware blobs. There is NO way that
processors made by US chip manufacturers do NOT contain a
On 07.12.2016 23:50, Alex Haydock wrote:
> On 07/12/16 21:45, diffusae wrote:
>> Hmm, interesting subject ...
>>
>> On 07.12.2016 21:35, Gumby wrote:
>>> Subject seems to have changed a bit, so not hijacking it.
>>> When thinking of any exploitation of firmware - should there be concerns
>>> of
On 07/12/16 21:45, diffusae wrote:
> Hmm, interesting subject ...
>
> On 07.12.2016 21:35, Gumby wrote:
>> Subject seems to have changed a bit, so not hijacking it.
>> When thinking of any exploitation of firmware - should there be concerns
>> of Intel's Management Engine in the CPU of any
Which "other parts" do you mean? The GPU blob or Raspbian?
You don't need to use the stock distribution.
On 07.12.2016 23:10, Duncan Guthrie wrote:
> What I was originally getting at was that the parts of the Raspberry Pi
> that are completely proprietary - while there is a free software
>
What I was originally getting at was that the parts of the Raspberry Pi
that are completely proprietary - while there is a free software
implementation of the GPU blob, most people don't use that, as they are
on stock Rasbian, which includes all the nasty "other parts" - are a
great
Hmm, interesting subject ...
On 07.12.2016 21:35, Gumby wrote:
> Subject seems to have changed a bit, so not hijacking it.
> When thinking of any exploitation of firmware - should there be concerns
> of Intel's Management Engine in the CPU of any relays
> running on "home hardware" in any
Subject seems to have changed a bit, so not hijacking it.
When thinking of any exploitation of firmware - should there be concerns
of Intel's Management Engine in the CPU of any relays
running on "home hardware" in any common unused pc or laptop?
Should that be a concern on ANY newer Intel
14 matches
Mail list logo