I would guess that not executing proprietary code is a good solution, but I
would also say, Leah probably will come up with something somewhere down the
road if it is needed.
:)
Link [1] in above should be,
https://marc.info/?l=linux-kernel=151717638018350
[Upon researching to buy a FSF RYF certified hardware, a few of which were
using Trisquel, reached here]
[avoiding if & buts at the risk of some of the below going wrong to keep the
post simple, links are provided for more details]
W.r.t GNU/Linux Kernel on Meltdown & Spectre:
a. Meltdown
>javascript
Well, FF was patched for metdownz. You can also mitigate spectre by disabling
jit in your browser - linky ->
https://trac.torproject.org/projects/tor/ticket/21011
*I can count the websites I allow javashit to run on the fingers of my left
hand. You get used to it, get much
"Librebooted computers will be affected by Meltdown and Spectre forever."
We don't know that it's unsolvable, all we know is that the solution chosen
by upstream relies on microcode changes.
I wonder if it would be possible to spark some community movement towards
alternate mitigation
"The first thing is, that it is in my opinion a mistake to assume that only
proprietary software can contain malicious code."
Although that's not what I said now, was it? I referred to running
"proprietary programs that they can never audit or trust." The difference
being that, if someone
On 08/02/18 09:08, wrote:
> So from my point of view there is now way to create a free and secure
> system
You got it wrong. It is "there is no way to create a free and
secure system", for Libreboot blocks all microcode updates. Librebooted
computers will be affected by Meltdown and
I agree with this 100%. There are so so so many bad things that are stopped
by just not running code you can't trust on your computer.
The solution that the Linux kernel developers went with is also dependent on
proprietary microcode updates. Without this, the changes to the kernel alone
do not completely mitigate.
The solution chosen by the Linux kernel developers isn't necessarily the only
possible one, though, so it
Correct me if I'm wrong, but I thought that both Meldown and Spectre had no
other solution on existing hardware that implementing a patch on the linux
kernel, which does have some overhead. So I don't really see where is the
problem.
"Are there any ideas or solutions to deal with this problems?"
Yes: Don't worry about it. If you think on it you will see this is a problem
specific to people that use proprietary software, that do their computing on
other people's computers (what some like the call "the cloud"), or that
> with a proprietary µcode and architecture, all those CPU's were already
compromised
That is, with or without ME.
Then, by "freedom and security" you mean immunity to hackerdom, and not to
instutional intelligence (Intel and various intelligence services they
possibly cooperate with).
Because, with a proprietary µcode and architecture, all those CPU's were
already compromised when they are first sold.
In a certain way it was possible, as the older CPUs have no ME, but now the
situation is even worse. These security issues make the core2 CPUs completely
unusable.
Don't get me wrong. I know that this was not the perfect solution in terms of
the dream of totally free hardware, but it was a
> So from my point of view there is now way to create a free and secure
system anymore
Given the closed architecture and microcode Intel/AMD/ARM CPU's have, was it
possible to do that in the first place, i.e. before meltdown and spectre?
The question I asked myself is how will libreboot project deal with Meltdown
and Spectre security issues.
Mostly all libreboot users are using affected old core2 CPUs and regardless
of whether libreboot is willing to implement microcode it is unlikely that
Intel will ever release firmware
16 matches
Mail list logo
