On Tue, 22 Feb 2022 14:35:19 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 24 Jan 2022 16:51:26 GMT, Alan Hayward wrote:
>> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 835:
>>
>>> 833: __ stp(rlocals, rcpool, Address(sp, 2 * wordSize));
>>> 834:
>>> 835: __ protect_return_address();
>>
>> Most of the changes to fix the tests
On Mon, 24 Jan 2022 17:07:54 GMT, Alan Hayward wrote:
> check_return_address() is being a huge help here
Yes, I appreciate that rejecting double signing is a good model.The surprise
was solely a reflection of my limited understanding.
> There's no obvious way to catch those issues.
Ok, well
On Mon, 24 Jan 2022 15:56:06 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 24 Jan 2022 15:56:06 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Thu, 13 Jan 2022 11:53:47 GMT, Alan Hayward wrote:
> Looks like they are all segfaults, which is exactly what I'd expect if a
> frame was missing a sign or auth. I'm fairly confident it's the same handful
> of issues over and over. I'll get onto debugging them a little more.
I was hoping
On Wed, 12 Jan 2022 17:08:34 GMT, Alan Hayward wrote:
> Is it worth holding this patch up for those fixes?
Probably. It depends on exactly what is failing. Can you provide more info?
-
PR: https://git.openjdk.java.net/jdk/pull/6334
On Mon, 15 Nov 2021 11:08:57 GMT, Andrew Haley wrote:
>>>whether this function authenticates or strips the address depends only on
>>>debugging?
>>
>> Yes. We only need to strip the value, because we're not jumping to the lr
>> value, only viewing it.
>>
>> The interface is different to a
On Mon, 15 Nov 2021 09:07:11 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Mon, 15 Nov 2021 09:07:11 GMT, Alan Hayward wrote:
>> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
>> of its uses is to protect against ROP based attacks. This is done by
>> signing the Link Register whenever it is stored on the stack, and
>> authenticating the value
On Thu, 11 Nov 2021 15:30:29 GMT, Alan Hayward wrote:
> Am I right is saying that for Macos, all generated code is remapped RO before
> execution?
Ah, no, it seems the code cache is not RWX all the time as far as Java threads
are concerned. The Macos/AArch64 code is strategically calling
On Thu, 11 Nov 2021 14:20:33 GMT, Florian Weimer wrote:
> Is the code still mapped read-write all the time?
That depends on what code you mean. The JVM code compiled from C++ sources is
mapped RO(X) in the text section like any compiled C/C++ code. Protection of
that code is covered by the
On Thu, 11 Nov 2021 14:53:54 GMT, Florian Weimer wrote:
>> I don't agree that this is incorrect, at least not for the stated reason.
>> The flag switches on a protection mechanism that guards against ROP attacks.
>> To my reading that does not imply it guards against all such attacks, merely
On Thu, 11 Nov 2021 14:20:20 GMT, Florian Weimer wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify branch protection configure check
>
> src/hotspot/cpu/aarch64/globals_aarch64.hpp line 115:
>
>> 113:
On Thu, 11 Nov 2021 11:19:03 GMT, Andrew Dinn wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5185:
>>
>>> 5183: // ROP Protection
>>> 5184:
>>> 5185: void MacroAssembler::protect_return_address() {
>>
>> We need proper, fu
On Wed, 10 Nov 2021 13:22:37 GMT, Andrew Haley wrote:
>> Alan Hayward has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify branch protection configure check
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5185:
>
>>
On Wed, 10 Nov 2021 12:32:53 GMT, Alan Hayward wrote:
> PAC is an optional feature in AArch64 8.3 and is compulsory in v9. One
> of its uses is to protect against ROP based attacks. This is done by
> signing the Link Register whenever it is stored on the stack, and
> authenticating the value
On Wed, 3 Nov 2021 11:54:39 GMT, Aleksey Shipilev wrote:
> JDK-8182285 added the incremental build capabilities for modules, by hashing
> the APIs of each module.
>
> The original change uses MD5, which is quite weak, and JDK-8214483 allows
> `MessageDigest` to have no MD5 implementation.
please help to take a look again? OK for jdk/jdk?
That looks good to me.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
SVE patch going in as is since that merely corrects the
status quo to allow for SVE instructions.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
required
though or even appropriate. There is already a precedent for keeping
generator code in the source tree and, when it is specific to a given
arch, keeping it next to the related source. The adlc generator code
sits in the shared source tree. The m4 file used to generate parts of
aarch64.ad is i
is_scalable() is different, while this is an
> assertion for ideal_reg of a given node.
Yes, my apologies for misreading that. These assertions should be retained.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
still running, and so far no new failure found.
Ok, well assuming they pass I am happy with this latest patch modulo the
tweaks above.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
are even when
running on x86_64 (and vice versa). Dev work on shared + x86_64-specific
code can also require making compatible changes to AArch64-specific classes.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registr
On 24/03/2020 09:10, Magnus Ihse Bursie wrote:
> On 2020-03-24 09:59, Andrew Dinn wrote:
>> I'm assuming that also implies it is trivial (because, copyright update
>> a side, it really is a 1-liner :-).
>
> For code in the build system, we do not have the Hotspot rules of
On 23/03/2020 18:38, Erik Joelsson wrote:
> Looks good.
Thanks for the review, Erik.
I'm assuming that also implies it is trivial (because, copyright update
a side, it really is a 1-liner :-).
I will push to the dev tree and request a backport to jdk14u.
regards,
Andrew D
.
JIRA: https://bugs.openjdk.java.net/browse/JDK-8241144
webrev: http://cr.openjdk.java.net/~adinn/8241144/webrev
Testing:
Built image and compiled + ran Hello World.
Built make target docs-jdk-api-javadoc and checked module
jdk.nio.mapmode was included in output
regards,
Andrew Dinn
Client VM build where C2 files are not in, this error occurs.
Ok, in that case the patch is good to push.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
1
> [4] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/323bd24c6520#l11.7
> [5] http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/d5d065957597#l86.56
Your explanation sounds correct and the change to arguments.cpp looks good.
Can you explain why you have modified sharedRuntime_aarch64.cpp to
includ
On 30/07/2019 14:25, Andrew John Hughes wrote:
> On 30/07/2019 09:48, Andrew Dinn wrote:
>> I agree that this is needed. I also understand why Andrew is loath to
>> see changes that are not upstream. However, in this case I don't think
>> we can avoid adding changes that ca
he jdk make process) is not an option in jdk8u because the make
processes run in separate trees. So, replicating the shared code seems
to be the only option.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registra
cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/
>>
>> Each of them has a reference to a plain patch file if you prefer to
>> review that.
>>
>> Thanks,
>> Severin
>>
>
> Ok. HotSpot, JDK & top look fine, but there seem to be a lot of
d this endeavour and
its present outcome.
As you say tuning the test group can be done over time as a follow-up.
The important thing is to quickly place devs in a position to easily
check that fixes have no unintended side-effects. Very nice!
regards,
Andrew Dinn
---
Senior Principal Software
o remove it as far as any contents are concerned. Indeed, I
told him this was ok in a review in the above thread after Pengfei
reported that OpenJDK built without the file being present.
As to the contents, the encoding defined in that file is completely
redundant (I don't really know how it got there
On 27/09/18 09:53, Andrew Haley wrote:
> http://cr.openjdk.java.net/~aph/8211207/
>
> follows the pattern of the x86 port.
Yes, looks good.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No.
t now) jdk10u be frozen i.e. no
updates not even security fixes. But don't worry! because jdk11u will be
created and will receive updates for long term. Meanwhile, the
developers are already working on jdk12 ...
> Sorry I new to this.
Yes, we were all new once -- so we know it's not always cle
take some of those steps slowly, one
at a time then I am for stability.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
build system to
accommodate that specific Ubuntu organization. I think this needs to be
addressed by the build system maintainers.
n.b. I have cross-posted this to build-dev.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales
; aarch64 arm64
arm64 is *not* a correct name for the AArch64 architecture. There is in
fact no arm64 architecture. The latter name has been used to identify
the Oracle-developed port but that fact does not sanction its use for
OS_ARCH.
regards,
Andrew Dinn
---
Senio
Hi Vladimir,
On 31/10/16 11:38, Andrew Dinn wrote:
> On 28/10/16 16:52, Vladimir Kozlov wrote:
>> Thank you, Andrew, for verifying that build changes do not break AArch64.
>> But it would be nice if you can also apply Hotspot changes (revert
>> hs.make.webrev changes before
.vm.ci/share/classes/module-info.java:43:
error: module not found: jdk.vm.compiler
jdk.vm.compiler;
. . .
I assume fixing this second problem requires me to clone the graal-core
repo into my tree and the apply the graal.webrev patch then rebuild.
I am currently looking into th
416.
1) Do I need to use any specific configure options to exercise these
specific changes satisfactorily on AArch64?
2) Do I need to include any further changes in order to test more fully?
regards,
Andrew Dinn
---
organization which resulted from introduction of the
module system and thought you might be able to short-circuit the enquiry.
Anyway, I'm quite happy so long as Red Hat can produce releases which
allow the full core JDK runtime to be debugged from a Java debugger.
regards,
Andrew Dinn
---
Seni
in a position to
build (and keep on rebuilding) a Jigsaw JDK9 release from scratch.
Still, no doubt Oracle has its own reasons for adopting such a policy.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registratio
used to build a release accompany the release where possible.
So, I'd prefer for open code builds to be configured to include the jdk
package sources -- unless, of course, there is a good reason not to
include them.
regards,
Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK
45 matches
Mail list logo
