On Fri, 26 Jan 2018 18:47:28 +0100
"Jason A. Donenfeld" wrote:
> On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote:
> > a) The info is already trivially accessible via /proc/cpuinfo
>
> No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't
> show whether or not the kernel has go
On Fri, Jan 26, 2018 at 12:47 PM, Jason A. Donenfeld wrote:
> On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote:
>> a) The info is already trivially accessible via /proc/cpuinfo
>
> No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't
> show whether or not the kernel has gone to le
On Fri, Jan 26, 2018 at 5:43 PM, Alan Cox wrote:
> a) The info is already trivially accessible via /proc/cpuinfo
No, /proc/cpuinfo shows if the CPU itself has these bugs, but doesn't
show whether or not the kernel has gone to lengths to mitigate these
bugs.
# grep -o 'bugs.*cpu_meltdown' -m1 /pr
This sort of seems like painting a plate carrier onto a tshirt.
Attackers will know, one way or another, as we have illegitimate and
legitimate vectors for gaining information. Good ecosystem inhabitants
however will be in the dark because this proposes to obfuscate their
legitimate interfaces used
On Fri, 26 Jan 2018 13:31:58 +0100
"Jason A. Donenfeld" wrote:
> While it's public information if the CPU in general has spectre/meltdown
> bugs, it probably shouldn't be as globally obvious to all unprivileged
> users
As I replied to you last time you posted this
a) The info is already trivia
While it's public information if the CPU in general has spectre/meltdown
bugs, it probably shouldn't be as globally obvious to all unprivileged
users whether or not the kernel is doing something to mitigate those
bugs. While an attacker can obviously probe and try, there frequently is
a trade-off a
6 matches
Mail list logo
