Hello, On Sun, Jan 7, 2018 at 10:38 AM, Philipp Marek <philipp@xxxxxxxxxxxxx> wrote: > 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. >> > That's the whole point of the many bugs shown by Google: don't overtrust page table isolation. It's broken. > Because with the recent faults all the memory could be read, > and the kernel has all of RAM mapped. I think this is not really an issue - that's a problem that the KPTI patch will solve under linux (I don't know the status of this situation on other OSes, but I suspect some kind of mitigation is going to be implemented). The main problem is not related to meltdown (kernel memory read) but to spectre (disclosure of memory of other processes), and direct IO is not going to solve it - careful change of code will. > > > > 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. > > Best regards, -- Emmanuel Deloget _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
