From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751967AbdHGWOG (ORCPT ); Mon, 7 Aug 2017 18:14:06 -0400 Received: from fallback14.m.smailru.net ([94.100.179.44]:56692 "EHLO fallback.mail.ru" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751662AbdHGWOF (ORCPT ); Mon, 7 Aug 2017 18:14:05 -0400 X-Greylist: delayed 2470 seconds by postgrey-1.27 at vger.kernel.org; Mon, 07 Aug 2017 18:14:04 EDT Subject: Re: FSGSBASE ABI considerations To: Andy Lutomirski Cc: "Bae, Chang Seok" , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds , Borislav Petkov , Brian Gerst , Bart Oldeman References: <73bef0c2-f181-0626-2ac1-e4e0537ca851@list.ru> From: Stas Sergeev Message-ID: <31548334-01bf-caac-75ac-a4a70faca07a@list.ru> Date: Tue, 8 Aug 2017 00:32:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-MW X-7FA49CB5: 0D63561A33F958A5062BB45A51FF213EFEA1C06382954CBB0793BFA0D54FE078725E5C173C3A84C39472471D10B198B902FA1CB11267DDDDF65A62F6C9828292C4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F41B67924A99884D73B503F486389A921A5CC5B56E945C8DA X-Mailru-Sender: F1845AB6CCC9920DF7838D61D4D05C428262A505E543D327F2B4365DCB1EB2295FE9CD0FB4FA84C81653177920737CA72999BEE114A20FF4278B2D54D4112F244F0A872F021F905956A8FB0C6EBA5FCCEAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: OK X-7FA49CB5: 0D63561A33F958A50E6451276E4BE1ADB07102D7E818D3E67C325720BD823395462275124DF8B9C938130EB80001CEACE5BFE6E7EFDEDCD789D4C264860C145E X-Mailru-Sender: A5480F10D64C90051B732BAF0E936B4236C04670869F6A916B4082DCF5D549F68F834780009727FCBD9A213A94BF4775DDBB79867CC2C1EC5DD9ADBE8243F6ED0252A3EF2865ED2F733E9BFD465368085FEEDEB644C299C0ED14614B50AE0675 X-Mras: OK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 07.08.2017 19:20, Andy Lutomirski пишет: >> I think >> this is the half-step. It clearly shows that you don't want >> such state to ever exist, but why not to go a step further >> and just make the bases to be reset not only by any >> unrelated modify_ldt() call, but always on schedule? >> You can state that using wrgsbase on non-zero selector >> is invalid, reset it to LDT state and maybe send a signal >> to the program so that it knows it did something wrong. >> This may sound too rough, but I really don't see how it >> differs from resetting all LDT bases on some unrelated >> modify_ldt() that was done for read, not write. >> Or you may want to reset selector to 0 rather than >> base to LDT. > Windows does something sort of like this (I think), but I don't like > this solution. I fully expect that someone will write a program that > does: > > old = rdgsbase(); > wrgsbase(new); > call_very_fast_function(); > wrgsbase(old); > > This will work if GS == 0, which is fine. The problem is that it will > *also* work if GS != 0 with very high probability, especially if this > code sequence is right after some operation that sleeps. And then > we'll get random crashes with very low probability, depending on where > the scheduler hits. So, as Linus already pointed, if the fixup is to zero out the selector, then this will still work fine. >> I am far from the kernel development so my thoughts >> may be naive, but IMHO you should just disallow this >> by some means (like by doing a fixup on schedule() and >> sending a signal). No one will suffer, people will just >> write 0 to segreg first. Note that such a problem can >> be provoked by the fact that the sighandler does not >> reset the segregs to their default values, and someone >> may simply forget to reset it to 0. You need to remind >> him to do so rather than to invent the tricky code to >> do something theoretically correct. > I would *love* to disallow it. The problem is that I don't believe it > to be possible in a way that doesn't cause more problems than it > solves. I wonder if sending a signal (after doing a fixup) is too much of a punishment? > I'm trying to avoid a situation where we implement that policy and the > interaction with modify_ldt() becomes very strange. IMHO if you do the fixup on schedule (like setting the selector to zero), then the interaction with modify_ldt() is completely avoided, i.e. modify_ldt() should then never special-case the threads that did wrgsbase. So if something inconsistent comes out, then it was likely there already without wrgsbase.