From: Mathias Krause <firstname.lastname@example.org>
To: Aymeric Fromherz <email@example.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
WireGuard mailing list <firstname.lastname@example.org>
Subject: Re: [PATCH 0/2] wireguard-linux-compat: grsecurity compat patches
Date: Mon, 13 Dec 2021 15:33:26 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
yeah, don't worry. We can keep this change downstream in grsec. Dunno if
Jason wants to take it as well, his call. It was just a side observation
which came out of our need to read and understand the code to provide a
workaround for the gcc bug we were hitting.
Am 13.12.21 um 15:20 schrieb Aymeric Fromherz:
> Hi Mathias,
> Thanks for the comments. Unfortunately, changing "r" to "rm" for the out parameter in a systematic way is quite trick.
> Allowing arguments to be passed independently in a register or in memory is currently out of scope of the Vale model we use for verification.
> We must decide early on in the verification pipeline if the argument is passed in a register, or if it stored in memory.
> Doing this in a sound way would require a significant change to our (trusted) model.
> ----- Mail original -----
>> De: "Mathias Krause" <firstname.lastname@example.org>
>> À: "Aymeric Fromherz" <email@example.com>, "Jason A. Donenfeld" <Jason@zx2c4.com>
>> Cc: "WireGuard mailing list" <firstname.lastname@example.org>
>> Envoyé: Lundi 13 Décembre 2021 08:44:51
>> Objet: Re: [PATCH 0/2] wireguard-linux-compat: grsecurity compat patches
>> Hi Aymeric,
>> the changes look good to me -- quite what we already had in grsec. Just
>> one more nit. The constraints for the 'out' parameter in fmul(),
>> fmul2(), fsqr() and fsqr2() can be further lifted to "rm" as 'out' is
>> only referenced once. This allows gcc to choose either a register or a
>> memory operand, as it sees fit. In our experiments the latter lead to
>> much better code gen.
>> Am 11.12.21 um 17:35 schrieb Aymeric Fromherz:
>>> Thanks for the heads-up. We were being overly conservative during verification
>>> of inline assembly code in Vale, and marked several registers as possibly
>>> modified while they were only read.
>>> This is now fixed for fmul, fmul2, fsqr and fsqr2, and will be merged into the
>>> master branch of EverCrypt shortly.
>>> In the meantime, the diff for the resulting inline assembly after Vale codegen
>>> is available here:
>>> ----- Mail original -----
>>>> De: "Jason A. Donenfeld" <Jason@zx2c4.com>
>>>> À: "Mathias Krause" <email@example.com>, "aymeric fromherz"
>>>> Cc: "WireGuard mailing list" <firstname.lastname@example.org>
>>>> Envoyé: Vendredi 10 Décembre 2021 23:58:01
>>>> Objet: Re: [PATCH 0/2] wireguard-linux-compat: grsecurity compat patches
>>>> CC'ing in Aymeric, who's working on Vale's codegen.
>>>> On Thu, Dec 9, 2021 at 8:59 AM Mathias Krause <email@example.com> wrote:
>>>>> Am 08.12.21 um 15:56 schrieb Jason A. Donenfeld:
>>>>>> On Mon, Dec 6, 2021 at 10:00 PM Mathias Krause <firstname.lastname@example.org> wrote:
>>>>>>> Yes, probably, but you're mixing up the two.
>>>>>> Oh, thanks, right.
>>>>>> I'll talk to EverCrypt upstream and see.
>>>>> FWIW, 'out' is also wrongly flagged as output operand in fmul() and
>>>>> fmul2(). But making it an input operand needs more surgery, as the
>>>>> operand order changes and this requires some code churn.
next prev parent reply other threads:[~2021-12-13 14:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 13:27 Mathias Krause
2021-07-06 13:27 ` [PATCH 1/2] compat: better grsecurity compatibility Mathias Krause
2021-07-06 13:27 ` [PATCH 2/2] curve25519-x86_64: solve register constraints with reserved registers Mathias Krause
2021-08-08 20:53 ` [PATCH 0/2] wireguard-linux-compat: grsecurity compat patches Jason A. Donenfeld
2021-08-09 10:13 ` Mathias Krause
2021-12-03 22:20 ` Jason A. Donenfeld
2021-12-03 22:25 ` Jason A. Donenfeld
2021-12-06 14:04 ` Mathias Krause
2021-12-06 14:48 ` Jason A. Donenfeld
2021-12-06 16:24 ` Mathias Krause
2021-12-06 16:27 ` Jason A. Donenfeld
2021-12-06 18:18 ` Mathias Krause
2021-12-06 18:55 ` Jason A. Donenfeld
2021-12-06 19:28 ` Jason A. Donenfeld
2021-12-06 20:54 ` Mathias Krause
2021-12-08 14:56 ` Jason A. Donenfeld
2021-12-06 21:00 ` Mathias Krause
2021-12-08 14:56 ` Jason A. Donenfeld
2021-12-09 7:59 ` Mathias Krause
2021-12-10 22:36 ` Jason A. Donenfeld
2021-12-10 22:58 ` Jason A. Donenfeld
2021-12-11 16:35 ` Aymeric Fromherz
2021-12-12 21:43 ` Jason A. Donenfeld
2021-12-13 7:54 ` Mathias Krause
2021-12-13 11:36 ` Jason A. Donenfeld
2021-12-13 16:29 ` Jason A. Donenfeld
2021-12-13 16:46 ` Mathias Krause
2021-12-13 7:44 ` Mathias Krause
2021-12-13 14:20 ` Aymeric Fromherz
2021-12-13 14:33 ` Mathias Krause [this message]
2021-12-13 14:37 ` Jason A. Donenfeld
2021-12-13 16:32 ` Mathias Krause
2021-12-13 16:33 ` Jason A. Donenfeld
2021-12-13 16:39 ` Mathias Krause
2021-12-13 16:53 ` Jason A. Donenfeld
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).