In regards to Meltdown, is there any good reason not to have upgraded to Linux kernel 4.15 yet?
160 views
Skip to first unread message
kapikti@mail2tor
Jan 8, 2018, 8:05:47 PM1/8/18
to qubes...@googlegroups.com
4.15 has KPTI which blocks Meltdown. I see a lot of talk on this mailing
list about more exotic solutions like switching to 32-bit VMs or HVMs
exclusively, which certainly could be good for blocking both Meltdown and
some varieties of Spectre, but it would seem to me like blocking Meltdown
itself (as it is the easiest to exploit) should be the top priority, and
the most effective way to do this immediately is just to upgrade to 4.15.
Are there any plans in the works to do this?
list about more exotic solutions like switching to 32-bit VMs or HVMs
exclusively, which certainly could be good for blocking both Meltdown and
some varieties of Spectre, but it would seem to me like blocking Meltdown
itself (as it is the easiest to exploit) should be the top priority, and
the most effective way to do this immediately is just to upgrade to 4.15.
Are there any plans in the works to do this?
Marek Marczykowski-Górecki
Jan 8, 2018, 8:09:43 PM1/8/18
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Just upgrading Linux (either dom0, VM, or both) does not help in
virtualized environment (especially PV used in Qubes 3.2). What would be
needed, is to apply KPTI-like approach to Xen itself, which is not ready
yet and probably won't be anytime soon. This is why we're discussing
alternative solutions.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpUFi4ACgkQ24/THMrX
1ywHcAf/ZAeCIiy+MggVN5pRBPhQ9Q7RuSZImy0qUAkhpvME0Q1XVSHYaCoPMaF4
yp9IIRxlg7Va2yxjffCIF3lldN5BVMGKrnwR7oghxLB81z958/5iwG0rG9cGN6Go
lsKxHCopvlBVjU1HOUTzKoNH7sOB0XJvKwVJcwqhNBoLNxnXmjFjczW7W4MuZI7Q
16hF7k7+uMeSOX9QlKKxxf0FaTS2oWhRz/f6lhsVIh1G++Zp2ATQSaPCxq3Szc7k
N1AKtj+WFFwfcCsxN+oNYbX3OnDeLAx5IstKzvMDPwREsS9K3RID5udT6hog54n7
fBy/1p0FGIAwEUybN2Szfl8qV0QUSA==
=o/5S
-----END PGP SIGNATURE-----
Hash: SHA256
virtualized environment (especially PV used in Qubes 3.2). What would be
needed, is to apply KPTI-like approach to Xen itself, which is not ready
yet and probably won't be anytime soon. This is why we're discussing
alternative solutions.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpUFi4ACgkQ24/THMrX
1ywHcAf/ZAeCIiy+MggVN5pRBPhQ9Q7RuSZImy0qUAkhpvME0Q1XVSHYaCoPMaF4
yp9IIRxlg7Va2yxjffCIF3lldN5BVMGKrnwR7oghxLB81z958/5iwG0rG9cGN6Go
lsKxHCopvlBVjU1HOUTzKoNH7sOB0XJvKwVJcwqhNBoLNxnXmjFjczW7W4MuZI7Q
16hF7k7+uMeSOX9QlKKxxf0FaTS2oWhRz/f6lhsVIh1G++Zp2ATQSaPCxq3Szc7k
N1AKtj+WFFwfcCsxN+oNYbX3OnDeLAx5IstKzvMDPwREsS9K3RID5udT6hog54n7
fBy/1p0FGIAwEUybN2Szfl8qV0QUSA==
=o/5S
-----END PGP SIGNATURE-----
Foppe de Haan
Jan 10, 2018, 2:48:15 AM1/10/18
to qubes-devel
Marco Giglio
Jan 10, 2018, 6:47:25 AM1/10/18
to qubes...@googlegroups.com
It wouldn't help at all if the key is kept in memory. Via Meltdown, an
attacker in a PV VM you would be able to see the entire memory of the
host machine, including the encryption keys. There are been some
experiments in the past with in-cache AES keys for memory encryption
with Linux Kernels (e.g TRESOR), but they didn't withstand successive
security scrutiny.
On 01/10/2018 07:48 AM, Foppe de Haan wrote:
> On Tuesday, January 9, 2018 at 2:09:43 AM UTC+1, Marek
> Marczykowski-Górecki wrote:
> >
>
> ********* *BEGIN ENCRYPTED or SIGNED PART* *********
> You received this message because you are subscribed to the Google
> Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/7d2b228f-18e5-4af2-9a0c-90cf62734a62%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
attacker in a PV VM you would be able to see the entire memory of the
host machine, including the encryption keys. There are been some
experiments in the past with in-cache AES keys for memory encryption
with Linux Kernels (e.g TRESOR), but they didn't withstand successive
security scrutiny.
On 01/10/2018 07:48 AM, Foppe de Haan wrote:
> On Tuesday, January 9, 2018 at 2:09:43 AM UTC+1, Marek
> Marczykowski-Górecki wrote:
> >
>
>
> > On Tue, Jan 09, 2018 at 12:26:24AM -0000, kapikti@mail2tor wrote:
> > > 4.15 has KPTI which blocks Meltdown. I see a lot of talk on this
> mailing
> > > list about more exotic solutions like switching to 32-bit VMs or HVMs
> > > exclusively, which certainly could be good for blocking both
> Meltdown and
> > > some varieties of Spectre, but it would seem to me like blocking
> Meltdown
> > > itself (as it is the easiest to exploit) should be the top
> priority, and
> > > the most effective way to do this immediately is just to upgrade
> to 4.15.
> > > Are there any plans in the works to do this?
> >
> > Just upgrading Linux (either dom0, VM, or both) does not help in
> > virtualized environment (especially PV used in Qubes 3.2). What would be
> > needed, is to apply KPTI-like approach to Xen itself, which is not ready
> > yet and probably won't be anytime soon. This is why we're discussing
> > alternative solutions.
> >
> > On Tue, Jan 09, 2018 at 12:26:24AM -0000, kapikti@mail2tor wrote:
> > > 4.15 has KPTI which blocks Meltdown. I see a lot of talk on this
> mailing
> > > list about more exotic solutions like switching to 32-bit VMs or HVMs
> > > exclusively, which certainly could be good for blocking both
> Meltdown and
> > > some varieties of Spectre, but it would seem to me like blocking
> Meltdown
> > > itself (as it is the easiest to exploit) should be the top
> priority, and
> > > the most effective way to do this immediately is just to upgrade
> to 4.15.
> > > Are there any plans in the works to do this?
> >
> > Just upgrading Linux (either dom0, VM, or both) does not help in
> > virtualized environment (especially PV used in Qubes 3.2). What would be
> > needed, is to apply KPTI-like approach to Xen itself, which is not ready
> > yet and probably won't be anytime soon. This is why we're discussing
> > alternative solutions.
> >
> > --
> > Best Regards,
> > Marek Marczykowski-Górecki
> > Invisible Things Lab
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> >
>
> ********** *END ENCRYPTED or SIGNED PART* **********
> > Best Regards,
> > Marek Marczykowski-Górecki
> > Invisible Things Lab
> > A: Because it messes up the order in which people normally read text.
> > Q: Why is top-posting such a bad thing?
> >
>
>
> I'm guessing software memory encryption (comparable to what AMD offers
> via SME/SEV for Ryzen Pro / Epyc -- transparent encryption with keys
> known only to the VM/HV instance, generated on boot) is completely
> unfeasible?
>
> --
> I'm guessing software memory encryption (comparable to what AMD offers
> via SME/SEV for Ryzen Pro / Epyc -- transparent encryption with keys
> known only to the VM/HV instance, generated on boot) is completely
> unfeasible?
>
> You received this message because you are subscribed to the Google
> Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to qubes-devel...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-devel/7d2b228f-18e5-4af2-9a0c-90cf62734a62%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Jim
Jan 10, 2018, 8:03:54 AM1/10/18
to Marco Giglio, qubes-devel
On Wed, 10 Jan 2018 11:47:20 +0000, Marco Giglio <marco...@gmail.com> wrote:
> It wouldn't help at all if the key is kept in memory. Via Meltdown, an
> attacker in a PV VM you would be able to see the entire memory of the
> host machine, including the encryption keys. There are been some
> experiments in the past with in-cache AES keys for memory encryption
> with Linux Kernels (e.g TRESOR), but they didn't withstand successive
> security scrutiny.
AFAIK, the Epyc cpu keeps the keys in a Cortex A5 processor nearby.
> It wouldn't help at all if the key is kept in memory. Via Meltdown, an
> attacker in a PV VM you would be able to see the entire memory of the
> host machine, including the encryption keys. There are been some
> experiments in the past with in-cache AES keys for memory encryption
> with Linux Kernels (e.g TRESOR), but they didn't withstand successive
> security scrutiny.
Wikipedia is paraphrased below but it's all moot unless AMD decide to open their toolchain, firmware and firmware documentation. I mean, why should we trust their "Secure Processor?"
From Wikipedia;
"Zen added the support for AMD's Secure Memory Encryption (SME) and AMD's Secure Encrypted Virtualization (SEV). Secure Memory Encryption is real time memory encryption done per page table entry. This is done utilizing the onboard "Security" Processor (ARM Cortex-A5) at boot time to encrypt each page, allowing any DDR4 memory (including nonvolatile varieties) to be encrypted. AMD SME also makes the contents of the memory more resistant to memory snooping and cold boot attacks....
The Secure Encrypted Virtualization (SEV) feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high performance encryption engine which can be programmed with multiple keys for use by different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes an API for these tasks."
Reply all
Reply to author
Forward
0 new messages