All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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: link
Be 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.