> If simply being connected to the internet is risky enough that
> your machine can be compromised
Incidentally, as the leakage is bits over time. OpenSSH added this defence.
Add protection for private keys at rest in RAM against speculation and memory
sidechannel attacks like Spectre, Meltdow
On 2020-06-12 00:47, joe mcguckin wrote:
> Yes, of course they have internet connections, but I don't run virtualization
> software. It's my understanding that most of these
> bugs have to do with information leaking from one process or VM to another or
> with a process trying to escape from it's
Yes, of course they have internet connections, but I don't run
virtualization software. It's my understanding that most of these
bugs have to do with information leaking from one process or VM to another
or with a process trying to escape from it's user process into a higher
privileged one. If
>Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer).
>
>It's my understanding that there is a significant performance penalty
>and I
>don't share my machines
>with anyone else, so I'm not concerned with information leaking between
>
It is likely more dangerous, than you realis
On Thursday, 11 June 2020 01:45:53 UTC+1, joe mcguckin wrote:
>
> Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer).
> It's my understanding that there is a significant performance penalty and I
> don't share my machines
> with anyone else, so I'm not concerned with informati
Actually, I'd like to turn off all the cpu bug fixes (e.g. row hammer).
It's my understanding that there is a significant performance penalty and I
don't share my machines
with anyone else, so I'm not concerned with information leaking between
processes.
Joe
On Wednesday, June 10, 2020 at 3:01
>> What about where there are multiple cpus? My servers have 2, 6 core
>> Xeons. With hyper threading, it looks like 24 cores available to
>Linux.
I know the latest issues also affect hyper threading/SMT but you shoukld
consider switching it off or using AMD, if you care about security. OpenBSD
seems to me whats relevant is that the core count is 'below' in the
software stack, so transparent, so here it will be 24.
but, like all progs, go progs use what they're told about, so you could
'see' less or you COULD be running inside an emulator that mimics,
potentially very slowly, any numb
On Wednesday, June 10, 2020 at 1:03:41 PM UTC-7, joe mcguckin wrote:
>
> I read somewhere that the default # of GO threads is the number of cores
> of the cpu.
>
> What about where there are multiple cpus? My servers have 2, 6 core
> Xeons. With hyper threading, it looks like 24 cores available
2020. június 10., szerda 22:03:41 UTC+2 időpontban joe mcguckin a
következőt írta:
>
> I read somewhere that the default # of GO threads is the number of cores
> of the cpu.
>
> What about where there are multiple cpus? My servers have 2, 6 core
> Xeons. With hyper threading, it looks like 24 c
10 matches
Mail list logo
