PEM file opened without DIRECT I/O which makes private key readable by attacker exploiting MELTDOWN

[Philipp Marek]

>> I think we are possibly interested in switching to DIRECT IO (given 
>> that it
>>> bypasses any caching system including page cache) when reading *.PEM 
>>> file
>>> 
>> Sorry, but this makes no sense.
>> The data could just as well be read from the SSH process
>> memory space.
> I think that's actually not true. SSH process's stack and heap aren't
> mapped/stored into the kernel space mapped in all user space programs, 
> so
> how come a malicious program running in victim's system could have 
> access
> to stack/heap memory of SSH process which is only mapped in its address
> space? Please correct me if I'm wrong.
Because with the recent faults all the memory could be read,
and the kernel has all of RAM mapped.


>> Direct IO has some additional complexity; this may well
>> be avoided.
> Actually, it's only about adding a flag to open and making sure IO is 
> DMA
> aligned.
Ha! If only.

What alignment would you use? open(2) says

   > In Linux alignment restrictions vary by filesystem
   > and kernel version and might be absent entirely.
   > However there is currently no filesystem-independent
   > interface for an application to discover these
   > restrictions for a given file or filesystem.

and

   > EINVAL The filesystem does not support the O_DIRECT flag.

So it's not quite that easy.


Furthermore -- as you said, direct IO means no page cache.

Well, that means that _every_ access has to be done from (or to) stable
storage... now imagine a loop going to a few hundred servers, or having
the home directory with the private key on a network filesystem, etc.

That's a lot of seeks and/or transfer operations.



So, please don't do that.