The way I look at it is this:
Regardless of what's on your system, do the following: install free
software, don't install proprietary software.
The FSF recommends installing free software on top of proprietary
firmware that can't be replaced in the same way that they recommend
installing free
Man, shouldn't something this important be Public Domain? Screw the
copyrights, this needs to be accessible to EVERYBODY.
signature.asc
Description: This is a digitally signed message part
> Just a theory:
The moment I posted this, it occured to me that should it be the case, then
the vulnerabilities made public would be highly localized and easy to fix
with just a microcode upgrade. But the situation with meltdown and spectre is
more complex, requiring both microcode
> nobody knows if there is something worse
> inside the microcode (maybe improved backd00r)
Good point.
It is also possible that meltdown and spectre were already long known by
Intel and AMD, but only recently made public by them (via indirect channels)
so that they get to install a better
> Taking preventive measures seems practical to me.
Of course. You don't go out naked in winter and dress after you freeze. You
dress first. You have a direct experience to base you actions or. But with
computers it is all based on recommendations (unless you write the program,
in which
> That is not immediately practical.
> It would be if you were in an actual situation which is threatening to your
health. But are you? Or is it a fear that one day you may be (a non-fact
ATM), so that you are taking preemptive measures?
Taking preventive measures seems practical to me.
> Then let’s extend the metaphor to the immediately practical. I haven't
seen a poliovirus, but I trust getting a polio vaccine will help prevent me
from getting polio.
That is not immediately practical.
It would be if you were in an actual situation which is threatening to your
health.
> Those are all things which have no or very little relation to your life. So
trust or no trust - it really doesn't expose you to any risk. But when your
life is based on a computer which can be modified remotely by an evil expert
and so create a disaster for you - that is something entirely
> I haven't directly seen an electron or the dwarf planet Pluto. I haven't
been to Thailand or Angola. Nor have I touched the original Rosetta Stone or
Terracotta Army.
Those are all things which have no or very little relation to your life. So
trust or no trust - it really doesn't expose
> FSF proponents here would argue that through trust (in so called community)
you get the necessary certainty. But as I have said on other occasions -
trust is a belief. It creates more uncertainty as it is not based on direct
observation but on an idea. When you look a the tree outside your
>The tree is there, you can see it, touch it. You don't need a community of
experts to provide certifications and endorsements that there is a tree.
I beg to differ
I can easily go full-shit-philosophical about it until I really convince my
self there really is no tree and no observer either
> Then how can we depend on the possibility of catching usage of undocumented
instructions in Intel's binary code base?
FSF proponents here would argue that through trust (in so called community)
you get the necessary certainty. But as I have said on other occasions -
trust is a belief. It
>The problem is that no body can see the code of that crap, nobody knows if
there is something worse inside the microcode (maybe improved backd00r). So I
won't use microcrap. So maybe we are f***ed.
Hehe, right? In order to fix a vulnerability you install a backdoor \o/
That would be very
..ughhh, which reminded me I need to tcpdump da netsurfy, meh.
Yes, I responded to you too hastily and realized afterward that my response was
unfair.
> Really?
Your punch analogy misses my point. Accepting a microcode upgrade from Intel
is more analogous to accepting security patches from Microsoft. As in, by
installing Windows, one already acknowledges being a vassal to Microsoft
upfront. From then on, one cannot protect oneself from
> http://lists.phcomp.co.uk/pipermail/arm-netbook/2017-December/015062.html
It's been a while since I read something that made me so optimistic. Thanks for
the link.
To clarify, if someone were to refuse to support RISC-V because they felt that
repurposed Intel tech was good enough despite its freedom and security issues,
that would indeed be strange. If that's what you meant I apologize for putting
words in your mouth.
> So, gladly (or otherwise) accepting factory-loaded proprietary
> microcode, and yet rejecting an upgrade, is just... strange, if you
> ask me.
Really? Because not all undesirable things can be avoided at this time we
should not try to avoid any of them? Suppose I approached you from behind and
> So perhaps it can't really be fixed with
> software patches but indeed just 'mitigated'.
Note that these mitigations are only good against hackers and criminals -
they have no effect on Intel, as long as the microcode is proprietary. And it
doesn't matter if the it is factory loaded or
Please consider making an exception when interesting stuff like this comes
up. :)
I can't download it because I am bound by 1 GB/mo quota - not because I find
it unworthy. The parts in my explanation regarding information quality, text
browsing, etc. was only there in order to explain why I have such a low plan
as 1 GB/mo.
But the thing would be that, if you were to take the time to listen to John's
talk, they're not saying that that stuff is OK. You mentioned another forum
thread. It's important remember that other people talking is not the FSF.
This is why I steered you to them. To hear things out of the
Hopefully you would consider this talk to be of high quality, not a junk yard
with low information quality. I have found all of the Free As In Freedom
episodes to be very good. To my knowledge no one has transcribed this or any
other episode of Free As In Freedom. The duration of the file is
The problem is that no body can see the code of that crap, nobody knows if
there is something worse inside the microcode (maybe improved backd00r). So I
won't use microcrap. So maybe we are f***ed.
> Why not? It should be as straightforward as:
> wget http://faif.us/cast-media/FaiF_0x43_GNUnion.ogg
Well I didn't want to stray off topic, so I had been a bit terse on the
subject. Let me explain why (it is a bit personal)
Basically I don't like the way internet is evolving from an
"Unfortunately I can't view/download online multimedia and the issue is
covered in Q/A which is in MM form, so I can't listen to John Sullivan's
explanation."
Why not? It should be as straightforward as:
wget http://faif.us/cast-media/FaiF_0x43_GNUnion.ogg
> http://faif.us/cast/2013/oct/17/0x43/
Unfortunately I can't view/download online multimedia and the issue is
covered in Q/A which is in MM form, so I can't listen to John Sullivan's
explanation.
Anyone cares to share the gist of it, or provide a link to an abstract in
text? (any text
Rather than me explaining it, why not listen to John Sullivan? He's Executive
Director at the Free Software Foundation and gave a talk called State of the
GNUnion. This question was discussed during the Q session. I encourage you
to listen to it: http://faif.us/cast/2013/oct/17/0x43/
The Q
Linux 4.15 Git kernel built with GCC 8.0.1 and full Retpoline protection as
well as the yet-to-be-merged RETPOLINE_UNDERFLOW support for Skylake and
Kabylake systems.
That is what we need if we don`t want intel closed microcode.
> Heh, am I doing it right mate joe? :P
This works too. I don't know what benefit you may have from blocking
1st-party media, I don't block this. I use (excerpt):
* * * block
* * frame block
* * other block
* * script block
* * xhr block
* 1st-party * allow
* 1st-party frame allow
This
>I think that if XHR is blocked, JS cannot steal info from your RAM and send
it to another host. Additionally if cookies are blocked JS cannot store a
'state' which can be transmitted via HTTP in following site navigation.
uMatrix is a great extension which helps to control all that.
Heh,
Browsers themselves (even the free ones) have various issues:
https://trisquel.info/en/forum/web-browser
Browser extensions are based on JavaScript code. Perhaps there are other
parts of the browser itself which is JS (I don't know but I wouldn't be
surprised). JS itself is not dangerous
I did some searching and found this:
https://www.dcddcc.com/docs/2014_paper_microcode.pdf
Section 2, paragraph 3 explains that microcode itself is proprietary, i.e.
this is how the CPU's are made and sold.
https://libreboot.org/faq.html#microcode
"The updates are proprietary, and are
> There are numerous mitigations for Spectre that won't work on libre
> systems because they require (proprietary) microcode changes which
> neither Trisquel nor I will provide. For obvious reasons of them
> being proprietary.
> I understand that those dedicated to software freedom would not
>
"I mean, don't this attacks have to be executed in my computer?"
Yes.
"If I don't use JavaScript in my browser, and only use free software, is
there a way I could still be attacked?"
It probably helps but a program being free software doesn't mean it's free of
problems (a concrete example
If I don't use JavaScript in my browser, and only use free software, is there
a way I could still be attacked? I mean, don't this attacks have to be
executed in my computer?
"So perhaps it can't really be fixed with software patches but indeed just
'mitigated'."
Indeed; they are all "mitigations." Plus: There are numerous mitigations for
Spectre that won't work on libre systems because they require (proprietary)
microcode changes which neither Trisquel nor I
> A false sense of security is worse than no security at all, see
--disclaimer
That's a key point for all these tests. Remember that side-channel-execution
is a hardware bug, not software. So perhaps it can't really be fixed with
software patches but indeed just 'mitigated'. Whoever makes
I'm knob, thought I already had done that.
Meltdown was fixed:
Spectre and Meltdown mitigation detection tool v0.31
Checking for vulnerabilities against running kernel Linux 4.14.14-gnu #1 SMP
Wed Jan 17 15:33:18 UTC 2018 x86_64
CPU is Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz
CVE-2017-5753
> Apparently the current packages in belenos are too old?
Maybe. If so, you can get a newer kernel from jxself's repo.
Hmm, installed latest lowlatency lts kernel:
Spectre and Meltdown mitigation detection tool v0.31
Checking for vulnerabilities against running kernel Linux 4.4.0-93-lowlatency
#116~14.04.1+7.0trisquel1 SMP PREEMPT Mon Aug 28 17:34:47 UTC 20 x86_64
CPU is Intel(R) Core(TM)2 CPU P8600 @
Another tool to test with:
https://github.com/speed47/spectre-meltdown-checker
Alternatively you can install the linux-lts-generic-xenial package. Really
everyone still using the default kernel ought to do this, the default kernel
no longer receives updates.
You could download a more recent kernel from jxself's repo.
https://jxself.org/linux-libre/
Per https://github.com/paboldin/meltdown-exploit my installation appears
vulnerable to Meltdown:
BIOS: Libreboot 20160907
VULNERABLE ON
3.13.0-137-lowlatency #186+7.0trisquel2 SMP PREEMPT Sat Dec 9 14:45:23 UTC
2017 x86_64
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
46 matches
Mail list logo
