From: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> To: "Tobin C. Harding" <me@tobin.cc> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>, linux-kernel <linux-kernel@vger.kernel.org>, kernel-hardening@lists.openwall.com Subject: Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses Date: Fri, 1 Dec 2017 18:33:40 +0530 [thread overview] Message-ID: <CAPDLWs9wJEyLrP7ox1AxXLRPByRvPHs=A3rw0CNTs4J+VmUboQ@mail.gmail.com> (raw) In-Reply-To: <20171129204812.GE6217@eros> Hi, Pl see my re inline below.. Will also follow up this mail with a patch with (minor) fixes for the last one Tobin sent, and, hopefully, that should mostly have the whole thing done (for now at least!).. Thanks, Kaiwan. On Thu, Nov 30, 2017 at 2:18 AM, Tobin C. Harding <me@tobin.cc> wrote: > On Wed, Nov 29, 2017 at 04:32:54PM +0530, Kaiwan N Billimoria wrote: >> This "fallback to 0xc0000000" I don't really agree with. >> Obviously, there are platforms out there that do not use a PAGE_OFFSET value of >> 0xc0000000. So I think that defaulting to this is kinda presumptive; >> much better, IMHO, >> if we just fail and ask the user to pass the "correct" PAGE_OFFSET value via >> the '--page-offset-32bit=' option switch. >> What do you say? > > If we fallback to some sane value (it does not have to be 0xc0000000 > but that seems the most obvious) then the script has more chance of > running by default. Why do I think it is better to run by default even > with the wrong virtual address spilt, well since the correct value is > basically just eliminating false positives (non-kernel addresses) it > seems more right to run by default with extra false positives than to > fail and place demands on the user. This will be especially useful if we > get the script running in any continuous integration tools. > > We should definitely be noisy if we fallback to the default value > though. Yes, that's a valid argument. Will go with this.. > I just tried to save and apply it on my end and it works. How are you > saving it? What email client are you using? Perhaps try to create a > simple patch yourself, email to yourself, save it and apply it to a > clean branch. Huh.. wierd issues on my end, I guess.. will sort it out, thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Kaiwan N Billimoria <kaiwan.billimoria@gmail.com> To: "Tobin C. Harding" <me@tobin.cc> Cc: Alexander Kapshuk <alexander.kapshuk@gmail.com>, linux-kernel <linux-kernel@vger.kernel.org>, kernel-hardening@lists.openwall.com Subject: [kernel-hardening] Re: [PATCH] leaking_addresses: add support for 32-bit kernel addresses Date: Fri, 1 Dec 2017 18:33:40 +0530 [thread overview] Message-ID: <CAPDLWs9wJEyLrP7ox1AxXLRPByRvPHs=A3rw0CNTs4J+VmUboQ@mail.gmail.com> (raw) In-Reply-To: <20171129204812.GE6217@eros> Hi, Pl see my re inline below.. Will also follow up this mail with a patch with (minor) fixes for the last one Tobin sent, and, hopefully, that should mostly have the whole thing done (for now at least!).. Thanks, Kaiwan. On Thu, Nov 30, 2017 at 2:18 AM, Tobin C. Harding <me@tobin.cc> wrote: > On Wed, Nov 29, 2017 at 04:32:54PM +0530, Kaiwan N Billimoria wrote: >> This "fallback to 0xc0000000" I don't really agree with. >> Obviously, there are platforms out there that do not use a PAGE_OFFSET value of >> 0xc0000000. So I think that defaulting to this is kinda presumptive; >> much better, IMHO, >> if we just fail and ask the user to pass the "correct" PAGE_OFFSET value via >> the '--page-offset-32bit=' option switch. >> What do you say? > > If we fallback to some sane value (it does not have to be 0xc0000000 > but that seems the most obvious) then the script has more chance of > running by default. Why do I think it is better to run by default even > with the wrong virtual address spilt, well since the correct value is > basically just eliminating false positives (non-kernel addresses) it > seems more right to run by default with extra false positives than to > fail and place demands on the user. This will be especially useful if we > get the script running in any continuous integration tools. > > We should definitely be noisy if we fallback to the default value > though. Yes, that's a valid argument. Will go with this.. > I just tried to save and apply it on my end and it works. How are you > saving it? What email client are you using? Perhaps try to create a > simple patch yourself, email to yourself, save it and apply it to a > clean branch. Huh.. wierd issues on my end, I guess.. will sort it out, thanks.
next prev parent reply other threads:[~2017-12-01 13:04 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-28 6:32 [PATCH] leaking_addresses: add support for 32-bit kernel addresses Tobin C. Harding 2017-11-28 6:32 ` [kernel-hardening] " Tobin C. Harding 2017-11-28 13:16 ` Alexander Kapshuk 2017-11-28 13:16 ` [kernel-hardening] " Alexander Kapshuk 2017-11-28 21:10 ` Tobin C. Harding 2017-11-28 21:10 ` [kernel-hardening] " Tobin C. Harding 2017-11-29 7:59 ` Alexander Kapshuk 2017-11-29 7:59 ` [kernel-hardening] " Alexander Kapshuk 2017-11-29 10:16 ` Tobin C. Harding 2017-11-29 10:16 ` [kernel-hardening] " Tobin C. Harding 2017-11-29 11:02 ` Kaiwan N Billimoria 2017-11-29 11:02 ` [kernel-hardening] " Kaiwan N Billimoria 2017-11-29 20:48 ` Tobin C. Harding 2017-11-29 20:48 ` [kernel-hardening] " Tobin C. Harding 2017-12-01 13:03 ` Kaiwan N Billimoria [this message] 2017-12-01 13:03 ` Kaiwan N Billimoria 2017-12-01 13:09 ` kaiwan.billimoria 2017-12-01 13:09 ` [kernel-hardening] " kaiwan.billimoria 2017-12-04 0:11 ` Tobin C. Harding 2017-12-04 0:11 ` [kernel-hardening] " Tobin C. Harding 2017-12-04 4:41 ` kaiwan.billimoria 2017-12-04 4:41 ` [kernel-hardening] " kaiwan.billimoria 2017-12-04 4:55 ` Tobin C. Harding 2017-12-04 4:55 ` [kernel-hardening] " Tobin C. Harding 2017-12-04 5:09 ` Kaiwan N Billimoria 2017-12-04 5:09 ` [kernel-hardening] " Kaiwan N Billimoria 2017-12-04 5:21 ` Kaiwan N Billimoria 2017-12-04 5:21 ` [kernel-hardening] " Kaiwan N Billimoria 2017-12-04 8:21 ` Tobin C. Harding 2017-12-04 8:21 ` [kernel-hardening] " Tobin C. Harding 2017-12-04 10:20 ` kaiwan.billimoria 2017-12-04 10:20 ` [kernel-hardening] " kaiwan.billimoria 2017-12-04 12:37 ` Alexander Kapshuk 2017-12-04 12:37 ` [kernel-hardening] " Alexander Kapshuk 2017-12-04 13:28 ` Kaiwan N Billimoria 2017-12-04 14:08 ` Kaiwan N Billimoria 2017-12-04 14:08 ` [kernel-hardening] " Kaiwan N Billimoria 2017-12-04 20:59 ` Tobin C. Harding 2017-12-04 20:59 ` [kernel-hardening] " Tobin C. Harding 2017-11-29 11:30 ` Alexander Kapshuk 2017-11-29 11:30 ` [kernel-hardening] " Alexander Kapshuk
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPDLWs9wJEyLrP7ox1AxXLRPByRvPHs=A3rw0CNTs4J+VmUboQ@mail.gmail.com' \ --to=kaiwan.billimoria@gmail.com \ --cc=alexander.kapshuk@gmail.com \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-kernel@vger.kernel.org \ --cc=me@tobin.cc \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.