On Thu, Jan 18, 2018 at 3:49 PM, Vít Šesták
wrote:
> On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote:
>> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote:
>> >
>> > * If an application does not mitigate
On Thursday, January 18, 2018 at 2:06:08 AM UTC+1, Marek Marczykowski-Górecki
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Sun, Jan 14, 2018 at 03:24:04AM -0800, Vít Šesták wrote:
> > But it could be useful to use 32-bit stubdoms for those reasons. They do
> > rather
On Wednesday, January 17, 2018 at 10:29:18 PM UTC+1, Ilpo Järvinen wrote:
> On Wed, 17 Jan 2018, Lorenzo Lamas wrote:
>
> > On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote:
> > > ## Qubes 3.2
> > >
> > > For Qubes 3.2, we plan to release an update that will make almost
On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote:
> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote:
> >
> > * If an application does not mitigate Spectre and attacker finds useful
> > entry point, attacker can read memory of the application (but nothing more).
> > * If
On Thursday, January 18, 2018 at 12:20:49 PM UTC-5, David Hobach wrote:
> On 01/18/2018 04:04 PM, cooloutac wrote:
> > SO it doesn't look like 4th or 5th generation boards are going to get a
> > bios patch. IS the bios patch nescessary?
>
> Meltdown can be patched on Kernel and/or Hypervisor
On Thu, January 18, 2018 6:00 pm, Nik H wrote:
> Reasoning: The entire point of HW virtualization is to have very fast and
> seamless context switching so that if I have 10 different VMs running,
> the processor does not lose performance from that. So you keep caches,
> and you keep speculatively
On Jan 16, 2018, at 2:56 AM, Vít Šesták
wrote:
>
> * If an application does not mitigate Spectre and attacker finds useful entry
> point, attacker can read memory of the application (but nothing more).
> * If VM kernel does not
On 01/18/2018 04:04 PM, cooloutac wrote:
SO it doesn't look like 4th or 5th generation boards are going to get a bios
patch. IS the bios patch nescessary?
Meltdown can be patched on Kernel and/or Hypervisor level with a
performance loss by doing in the Kernel what should be done by the CPU.
On Thu, January 18, 2018 3:04 pm, cooloutac wrote:
> But if you have to buy a new
> mobo and pc every year or two to stay up to date that is a sad future for
> most people.
Most people, but not the Intel board members and stockholders!
--
You received this message because you are subscribed to
SO it doesn't look like 4th or 5th generation boards are going to get a bios
patch. IS the bios patch nescessary?
Or Should we just assume our desktop pc's are about as secure as android phones
now? Are they no good after a year or two? I joke that real security costs
alot of money because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Jan 14, 2018 at 03:24:04AM -0800, Vít Šesták wrote:
> Good point, I forgot this one. of course, it would, but I am not sure if
> Qubes is ready for that.
>
> But it could be useful to use 32-bit stubdoms for those reasons. They do
>
On Wed, 17 Jan 2018, Lorenzo Lamas wrote:
> On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote:
> > ## Qubes 3.2
> >
> > For Qubes 3.2, we plan to release an update that will make almost all
> > VMs run in a fully-virtualized mode. Specifically, we plan to backport
> >
On Monday, January 15, 2018 at 12:57:09 PM UTC+1, awokd wrote:
> It matters a bit because Spectre is harder to exploit than Meltdown. IIUR,
> Qubes' design allowed it to constrict Meltdown to a single VM
Not in PV, which are primary type of VM in 3.2.
> I'm still
> somewhat unclear on how
On Mon, January 15, 2018 1:15 am, Nik H wrote:
> On Monday, January 15, 2018 at 12:20:48 AM UTC+7, Vít Šesták wrote:
>
>> As far as I understand it, microcode update cannot fix it. It just
>> brings some new instructions that can be used for Spectre fix. (But
>> they don't help on their own.)
>>
Good point, I forgot this one. of course, it would, but I am not sure if Qubes
is ready for that.
But it could be useful to use 32-bit stubdoms for those reasons. They do rather
I/O-bound work (=> minimal performance penalty) and they don't need so much
memory to utilize more than 32-bit
On Saturday, January 13, 2018 at 10:50:11 AM UTC-8, Vít Šesták wrote:
> I have one more idea: The Vixen patch could be useful for VMs with PCI
> devices. Memory balooning is not supported there anyway. QEMU in dom0 looks
> ugly, but this case is a bit different: AFAIU, the attacker can directly
On Saturday, January 13, 2018 at 1:19:18 PM UTC+1, Vincent Adultman wrote:
> IIUC this still seems fairly awful from a usability perspective if we think
> of the added cognitive load of watching what is running when and remembering
> or making choices on what to close / restart when (I'm reading
I have one more idea: The Vixen patch could be useful for VMs with PCI devices.
Memory balooning is not supported there anyway. QEMU in dom0 looks ugly, but
this case is a bit different: AFAIU, the attacker can directly talk to QEMU if
and only if she has escaped from PV. Maybe it is not nice,
On Friday, January 12, 2018 at 5:24:25 AM UTC-5, haaber wrote:
> >>
> >> so people saying the intel meltdown bios patch slows performance. I got
> >> an increase in performance lmao. probably depends on os though.
> >
> > but also in my particular case they also addressed other bugs, but
>> Only running VMs are vulnerable
>>
>> Since Qubes OS is a memory-hungry system, it seems that an attacker
>> would only be able to steal secrets from VMs running concurrently with
>> the attacking VM. This is because any pages from shutdown VMs will
>> typically very quickly get allocated to
> There are two shims: PV-in-HVM aka Vixen and PV-in-PVH aka Comet. Both
have limitations making them incompatible (or at least suboptimal) in
Qubes
Marek, thanks for the clarification. So, IIUC, Vixien's shim is no-go and
Comet's shim would do the same (but at higher cost) as migration to PVH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2018-01-12 04:24, haaber wrote:
>>>
>>> so people saying the intel meltdown bios patch slows
>>> performance. I got an increase in performance lmao. probably
>>> depends on os though.
>>
>> but also in my particular case they also addressed
>>
>> so people saying the intel meltdown bios patch slows performance. I got an
>> increase in performance lmao. probably depends on os though.
>
> but also in my particular case they also addressed other bugs, but intel
> pushed the bios patch for meltdown, so worth a check from your
23 matches
Mail list logo