public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: "Peter Müller" <peter.mueller@link38.eu>
To: development@lists.ipfire.org
Subject: [Discussion] Consequences of CPU vulnerabilities
Date: Wed, 15 Aug 2018 18:06:03 +0200	[thread overview]
Message-ID: <32c087b0-dfe6-986a-68ae-74820bb39962@link38.eu> (raw)

[-- Attachment #1: Type: text/plain, Size: 3763 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello *,

during the past months, more and more vulnerabilities in modern CPUs
were detected. At the moment, there is
- - Spectre v1 and v2
- - Meltdown (sometimes referred to as Spectre v3)
- - Spectre v4
- - a bunch of vulnerabilities similar to v4 (summarised as Spectre-NG)
- - Spectre v5
- - and a lot more, at least five of them undisclosed.

Needless to say, this complex is a total nightmare for anybody caring
about security - not only because of the technical issues, but mainly
due to very sloppy responses from the hardware vendors (I cannot resist
naming Intel here directly).

Further, the current CVE and patch situation (especially when it comes
to the Linux kernel) is completely confusing, making it nearly impossible
to check which has been backported whereto, addressing which security
bulletin. In my humble opinion, the significance of security has decreased
a lot and is still dropping. Being discontent with the overall security
situation in the Linux kernel, the handling of recent CPU vulnerabilities
did not help.

That being said, I would like to discuss some changes to improve security
in IPFire, most of them at kernel or sysctl level.

(a) Disable hyperthreading by default?
OpenBSD did so a while ago, arguing this makes some side-channel attacks
more complicated or even impossible. HT was the source of some serious
vulnerabilities in the past (starting around 2006), which is one reason
why I never liked it too much. Would you consider disabling it acceptable
(it will probably cause some performance impact)?

(b) Update kernel more frequently
It seems to be necessary to ship new kernels more frequently, as some
security fixes are backported to 4.14.x very quickly. Unfortunately, this
causes updates to become very big, as C121/122 turned out, and I am not
familiar with the procedure behind this. How often do we want to ship a
new kernel? Every second update? Every forth? I have no idea... :-)

(c) Introduce kernel and sysctl hardening
Fortunately, there are some configure flags and /etc/sysctl.conf settings
improving the overall situation:
https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings
Their implementation in IPFire is on my TODO list (forgive me for being
slow during the last time) and filed here: https://bugzilla.ipfire.org/show_bug.cgi?id=11659

How small should the chunks be here? A patch for every changed setting
or can portions be bigger (same applies on OpenSSH hardening as well)?
Just asking to avoid unnecessary noise afterwards.

Comments? Anything I forgot here?

Thanks, and best regards,
Peter Müller
- -- 
Microsoft DNS service terminates abnormally when it recieves a response
to a DNS query that was never made.  Fix Information: Run your DNS
service on a different platform.
		-- bugtraq
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEvP4SiGhEYDJyrRLk2UjyD317n2gFAlt0T2IACgkQ2UjyD317
n2h8XQ//bWEYXJPfVzocEd1yZTKaoCRc4VyVSugV0p8kHfd42CS8uA0Pp3mM3Bzy
cWWxu3ru7oDc344BD54jtdPHLYP6WidEOF6Omgd8xYoFudHBc1zodBnKfeMkFLmZ
0YwblIA4arg5pVmUiqrCiRbyn2B+07e8fYO9DyGKESfJHw/RwPzW7jhJv3J4R7+Z
wabLfxaF3rbgB264FZ0YcfA1XUswvlvE4eKxxaOEUfnis7dFcmKZHB+LiQsIMXDj
AshlnCuWl5r1OczAwlyQw4xEykyCEVDCeeoGjOyXqx373+ThaODSGQovOIEFxPz/
TCERMUQNvAZQ0mi113Nw8MIZ5ofCJWZZhYldxsYNptVk425BMH+7moQDDQfaWmWc
GW/10j+rJITRhaYDq3LRNu6qACPE2N/T/7vz5kl5vslbmQ0pBuIf9HpdVIFHr5t9
yBclnxBs3r8z7G74Jvv0c9oNX5kUZ3AXUttZDghJQVkw15AOa1oZfl8nLZtW3KL2
aaeW8o9h19SBhywmUNL/7VMssM8IHeKf2rkT+ybOUC52MtXHnGuSKSdrjtFhpnAe
h3irxsJf0EFjZoxq2id3vtOzX8BWFxGFKOHXog33dNlNKDD/COqv4iAx8tb0eyiS
9F49HlB4NDK5oT4SF+6HIzBp4MYv8nmkX6j+9TVTKfmFQbmzc9w=
=Y+k+
-----END PGP SIGNATURE-----

             reply	other threads:[~2018-08-15 16:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-15 16:06 Peter Müller [this message]
2018-08-16 12:20 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32c087b0-dfe6-986a-68ae-74820bb39962@link38.eu \
    --to=peter.mueller@link38.eu \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox