On Sun, Jan 7, 2018 at 7: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. >> > Because with the recent faults all the memory could be read, > and the kernel has all of RAM mapped. I was wrong here, thanks for pointing it out. Talked to Rik Van Riel who helped making kpti happen, and the kernel indeed maps all of physical memory in its address space. So private key going to page cache widens the time range that private key is vulnerable (stays there until purged which is a time proportional to memory available and caching frequency), whereas with direct io flag the private key would only be vulnerable while a ssh program is running. > > > > 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. > you're right, querying dma alignment may be specific to file system, like XFS when uses a different block size or it falls back to buffered mode. 4096 usually works but usually isn't enough for a widely used program which needs to work everywhere with all kind of settings. > > > 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. > Agree with all the sentiment here. thanks for your time in explaining this all! _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
