<a href=https://lead-market.ru>lead-market.ru</a>
Sun May 22 16:46:07 EDT 2022
ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa
key
sha256) header.d=gmail.com header.i=@gmail.com header.b=DAqk099R
header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
policy.published-domain-policy=none
policy.published-subdomain-policy=quarantine policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
policy.policy-from=p header.from=gmail.com; spf=pass
smtp.mailfrom=crossd@gmail.com smtp.helo=mail-oa1-f50.google.com;
x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
has been altered)) (Message modified while forwarding at Topicbox)
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
topicbox.com; h=mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-type:list-help:list-id:list-post
:list-subscribe:reply-to:content-transfer-encoding
:list-unsubscribe; s=sysmsg-1; t=1653251741; bh=lq5f6BuiCJVwbmjo
aLpeqPf01W8BWv5DiEcq40j71JY=; b=ATJJBjcQLHmBHX46mMrnCsXX7XvnLqoh
ChgemX8zDvoDAjogZtQVXmfAKXDfAtnIm7tH0OTmhimB7Kl5Tg3ME7llWxRqPSFR
zgyEB37hHg9+diQKOkGPVVRyslkivT4q/ZeMXwsMXtZYsU+ARSIUl0F7vChQd3H+
raSxCYai13g=
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t=
1653251741; b=pl1gPOg3JTwNGhW9RVBMWRe4n0wIireV380CcT9aiFxW/ty9xq
d6DE5k7T+TrjARPciOswK163eMsZvSpnVnFStXMRw5+xycm854USsT+YLRI0nf8H
/o3hxWkoUwn7Z9BPyywT1pwQR/gEo2Uu1qw2Suzu+Tsa0YnrptM2w7Jfg=
Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key
sha256) header.d=gmail.com header.i=@gmail.com header.b=DAqk099R
header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
policy.published-domain-policy=none
policy.published-subdomain-policy=quarantine policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
policy.policy-from=p header.from=gmail.com; spf=pass
smtp.mailfrom=crossd@gmail.com smtp.helo=mail-oa1-f50.google.com;
x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
has been altered)) (Message modified while forwarding at Topicbox)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t=
1653251608; b=Jklcw0e/I9p3DsDgGTUcjdsl79AhCJnPeC9AKQxOrBVngdU0UX
L9SkguCyhNTibfekDLEZN9RT3HNDUrFvLK3/3Rz1Q6x66KwQrEEl6s0cFRffhBJQ
SL5IKoNgN5Gu3NQDjVV2zyt0oyNPtYDk0NINHzHWAld+Y8rFDQDQFaMt3OonT5MH
eYZr/L3vTTK8PnyTUJZ+x7+A7mJy+FFlnMMI6kufm0pvBtXM41cDLtbTSWCLVe49
QIc8OcwYKpnq//fY86aBMAk1/IdaNBAjJPOJNL0NCKDCj/E+h1m0V3DQwdjcuXzD
wj6G94KYyQr7cGoJjRbtrlwqqdU54Z3+60Gw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
topicbox.com; h=mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-type; s=arcseal; t=1653251608;
bh=aFf+bZdyCxhUiAa43UInD+PPGwUXtLLlLzyC8rDBSXI=; b=gD8xLmPtGws5
C4KFgHRUGhr0rlmYKX6eZ9Golq1qKOE8LJarKizD48bwkVp0PKqrj1aFbCf7NbC0
FltZOEUjCzcA9i/d5ZAw1AG4ChU6Hn1NaAmv3XMpT604kX9sGd0Yi8vvB/BeQZqa
+nabKoAt459U6urHx24y15J0akKwsY45gK6ykdAzfyUtb6zLQGrw6caHhANfQEXX
nIfmOoybXHc7GFA6ggf/2cudJeldfEVwkRwXHjxdNeL6oFVhEGkXtZ1StyxiaWU9
ABO7OK3msVFWJsHKeUhCiWDfbLxTv1b1yDlCjlTegOuCD5XrGivrH3WdQwEfvzrw
jfVcZAdTJg==
ARC-Authentication-Results: i=1; tb-mx0.topicbox.com;
arc=none (no signatures found);
bimi=skipped (DMARC Policy is not at enforcement);
dkim=pass (2048-bit rsa key sha256) header.d=gmail.com
header.i=@gmail.com header.b=DAqk099R header.a=rsa-sha256
header.s=20210112 x-bits=2048;
dmarc=pass policy.published-domain-policy=none
policy.published-subdomain-policy=quarantine
policy.applied-disposition=none policy.evaluated-disposition=none
(p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p
header.from=gmail.com;
iprev=pass smtp.remote-ip=209.85.160.50 (mail-oa1-f50.google.com);
spf=pass smtp.mailfrom=crossd@gmail.com
smtp.helo=mail-oa1-f50.google.com;
x-aligned-from=pass (Address match);
x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net
header.i=@1e100.net header.b=CDt2UGgz;
x-me-sender=none;
x-ptr=pass smtp.helo=mail-oa1-f50.google.com
policy.ptr=mail-oa1-f50.google.com;
x-return-mx=pass header.domain=gmail.com policy.is_org=yes
(MX Records found:
alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com);
x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes
(MX Records found:
alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com);
x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384
smtp.bits=256/256;
x-vs=clean score=0 state=0
Received-SPF: pass
(gmail.com ... _spf.google.com: Sender is authorized to use
'crossd@gmail.com' in 'mfrom' identity (mechanism
'include:_netblocks.google.com' matched))
receiver=tb-mx0.topicbox.com;
identity=mailfrom;
envelope-from="crossd@gmail.com";
helo=mail-oa1-f50.google.com;
client-ip=209.85.160.50
From: Dan Cross <crossd@gmail.com>
Date: Sun, 22 May 2022 16:33:14 -0400
Subject: Re: [9fans] Aarch64 on labs|9legacy?
To: 9fans <9fans@9fans.net>
Topicbox-Policy-Reasoning: allow: sender is a member
Topicbox-Message-UUID: 7299f3e2-da0e-11ec-975f-b9a3b4f6b4e9
Archived-At:
<https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M29e6e0dfdc06aad0e373cbbd>
Reply-To: 9fans <9fans@9fans.net>
Topicbox-Delivery-ID:
2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:9e00e022-a139-11eb-b835-09bb272d11b0:M29e6e0dfdc06aad0e373cbbd:1:qNjvNsbATbQdeVm7QH9FyAdn49Il9yRm7pBQpdEjToE
On Sun, May 22, 2022, 4:16 PM adr <adr@sdf.org> wrote:
> Has someone done something with aarch64 on labs|9legacy?
> It's called arm64
>
> Great.
>
> Because with this 4 magical words I was supposed to find... what?
> Where? What are you talking about? Where is this work on Bell Labs'
> plan9 that I could find using the string "arm64" (which of course
> I knew already from 9front, the only distribution with aarch64
> support)? Even in Inferno there is no aarch64 support. Where are
> this people publishing aarch64 work in the labs distribution that
> I could fing using "arm64"? What are you talking about?
>
> But now after all the useful interesting contribution to the list,
> as usual, you have time to even express sarcasm.
>
> You haven't help me to find anything, you don't have to do it, of
> course, but then don't talk like you have done it.
>
I've known and observed Charles for a very long time, indeed. I can imagine
how you interpreted what he wrote as you have, but perhaps consider that he
didn't mean what he wrote in the way you have taken it.
A simple question, a fucking simple question and here we go with
> the trolling and the bullshit, I'm done with this fucking list.
>
Probably for the best.
- Dan C.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M29e6e0dfdc06aad0e373cbbd
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Sun May 22 16:22:31 EDT 2022
From: "Theo de Raadt" <deraadt@openbsd.org>
To: Caspar Schutijser <caspar@schutijser.com>,
Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Mail-Followup-To: Caspar Schutijser <caspar@schutijser.com>,
Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Subject: Re: firefox: pledge violation through pkcs11/smart card usage
Comments: In-reply-to Stuart Henderson <stu@spacehopper.org>
message dated "Sun, 22 May 2022 18:44:51 +0100."
Date: Sun, 22 May 2022 11:54:42 -0600
Sender: owner-ports@openbsd.org
Stuart Henderson <stu@spacehopper.org> wrote:
> On 2022/05/22 08:58, Theo de Raadt wrote:
> > The existing code uses mlock. It appears to be using mlock for a
> > privacy reason. But mlock has no privacy reason.
> > The mlock page does not make any privacy or security promises at all.
>
> OpenSC is used on Linux too, mlock there does give some guarantees:
>
> mlock(), mlock2(), and mlockall() lock part or all of the calling
> process's virtual address space into RAM, preventing that memory
> from being paged to the swap area.
>
> ...
>
> Memory locking has two main applications: real-time algorithms
> and high-security data processing. Real-time applications
> require deterministic timing, and, like scheduling, paging is one
> major cause of unexpected program execution delays. Real-time
> applications will usually also switch to a real-time scheduler
> with sched_setscheduler(2). Cryptographic security software
> often handles critical bytes like passwords or secret keys as
> data structures. As a result of paging, these secrets could be
> transferred onto a persistent swap store medium, where they might
> be accessible to the enemy long after the security software has
> erased the secrets in RAM and terminated. (But be aware that the
> suspend mode on laptops and some desktop computers will save a
> copy of the system's RAM to disk, regardless of memory locks.)
POSIX has this to say on the matter:
https://pubs.opengroup.org/onlinepubs/009696699/functions/mlock.html
None of what Linux is doing here is in the spec, and I would argue it isn't
even in the spirit of what mlock was for ("performance").
So maybe just #ifdef __linux__ that block, and submit back to upstream.
I really think replacing this with calloc_conceal(3) is junk science.
> > This library is used in a gigantic program which does a ton of other
> > memory allocations, which uses a huge number of other libraries which
> > do a ton of other memory allocations.
Is it used in libcrypto? No.
> It's used in smaller programs too. Like OpenSSH.
openssh does not use mlock.
We really never know when a 'secret' is going to be put into memory,
because noone built for that model of strict object handling. And
since openssh to a large degree uses libcrypto, it means there are
'un-mlocked secrets there also'. Even the bignum library used by
asn1 doesn't do this. In some classes of software, it is keys at the
bottom, and secrets above. It is junk science to secrecy-lock the
keys without secrecy-locking the user's data, as the purpose of the
keys is to provide a variety of security gaurantees to the various
kinds of data.
For this library, used in this application, to suddenly want this
requirement fulfilled in such a narrow scope, is completely pointless.
Maybe malloc -- and mmap for that matter -- should mlock all memory,
just in case the user of that memory should be better protected than
careful process memory management?
In an abundance of caution of course, why show any concern for the
downsides and consequences.
/sarcasm.
Sun May 22 16:22:17 EDT 2022
From: "Theo de Raadt" <deraadt@openbsd.org>
To: Caspar Schutijser <caspar@schutijser.com>,
Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Mail-Followup-To: Caspar Schutijser <caspar@schutijser.com>,
Landry Breuil <landry@openbsd.org>, ports@openbsd.org
Subject: Re: firefox: pledge violation through pkcs11/smart card usage
Comments: In-reply-to Stuart Henderson <stu@spacehopper.org>
message dated "Sun, 22 May 2022 13:15:03 +0100."
Date: Sun, 22 May 2022 08:58:36 -0600
Sender: owner-ports@openbsd.org
Stuart Henderson <stu@spacehopper.org> wrote:
> On 2022/05/22 13:49, Caspar Schutijser wrote:
> > I haven't tested this but shouldn't this be HAVE_CALLOC_CONCEAL?
I really don't understand the approach being taken here.
The existing code uses mlock. It appears to be using mlock for a
privacy reason. But mlock has no privacy reason.
The mlock page does not make any privacy or security promises at all.
At best it says "This region will be available in direct memory, without
having to retrieve it from some (vague) slower memory" It does not say
that a copy of this allocation won't go to swap. It also does not say
that the contents won't land in coredump. mlock is a weird performance
gaurantee system call which noone should actually use (and I want to
remove) because it locks resources other processes might require.
mlock is apparently being used for a reason that isn't specified or
documented.
But I want to understand what the goal here is.
A subset of memory allocations in one library is being treated this way,
for "secrecy" or "privacy".
This library is used in a gigantic program which does a ton of other
memory allocations, which uses a huge number of other libraries which
do a ton of other memory allocations.
Does that gigantic program keep track of any other secrets or privacy
information in the other memory allocations it makes?
Once this diff for this one library goes in, will that huge program
and all the libraries it use receive the same attention? I would estimate
it will require 10,000+ commits to the whole tree -- base and ports -- if
we wanted to actually solve this problem.
It won't happen.
Unfortunately, our calloc_conceal() is in the same boat. Using it in a few
corners of the tree ... feels so ineffective.
Sun May 22 16:19:18 EDT 2022
ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=none (no signatures
found); dmarc=pass policy.published-domain-policy=none
policy.published-subdomain-policy=none policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=none,d=none,d.eval=none)
policy.policy-from=p header.from=sdf.org; spf=pass smtp.mailfrom=adr@SDF.ORG
smtp.helo=mx.sdf.org; x-internal-arc=fail (as.1.topicbox.com=pass,
ams.1.topicbox.com=fail (message has been altered)) (Message modified while
forwarding at Topicbox)
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
topicbox.com; h=date:from:to:subject:in-reply-to:message-id
:references:mime-version:content-type:list-help:list-id
:list-post:list-subscribe:reply-to:content-transfer-encoding
:list-unsubscribe; s=sysmsg-1; t=1653250630; bh=+J1m5FhzWb1j6Bdj
cKn97CdvjuySr+J9n+Sl0RbRglM=; b=ZvaxWayAgRhNy/oyIhNp0SCdIjU2/agN
2HNkk3C/A9yt6lxnpi/tTlUzpaXDmSa25nxkNrD5+PtJYNVuWlWzyoMxYPcvtmF7
latPW5WpDJJk2VcuxzvApz2Vrv3cmKH6brB2GuvNWBFq49sd2f0xpR+s8jMx0hv/
zYTPFbsgQk8=
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t=
1653250630; b=V9J0TArMaIcsM6TcAppAWSHcAZgyOLhLzZpO7RfSHhlIVOLwAz
NvkoJLw5kwDcAsmbvsl4HGk6uN7p1YkC6hAR1EsIiBVZG6lw/vt7pkYS6+CgFLrF
HNBITIRynnTCeQs0flLP6uSQcuMdlpBXhmd4jddzk3r2NbvTIDfPDCios=
Authentication-Results: topicbox.com; arc=pass; dkim=none (no signatures
found); dmarc=pass policy.published-domain-policy=none
policy.published-subdomain-policy=none policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=none,d=none,d.eval=none)
policy.policy-from=p header.from=sdf.org; spf=pass smtp.mailfrom=adr@SDF.ORG
smtp.helo=mx.sdf.org; x-internal-arc=fail (as.1.topicbox.com=pass,
ams.1.topicbox.com=fail (message has been altered)) (Message modified while
forwarding at Topicbox)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t=
1653250509; b=VrqkscdOfF0ErQIyUPz85dffvQ5dbnrvDbrblucqbE7oVJQfgQ
YAZ95LdD01KoIi+2ioXmc9vhTTIvulPfqvdQuzBuwJ1z6/JCfewU3gW2cBu/EThz
vUKKzIEfLkXFtHCYarWhwEbggU1iRivge2kBq7zUdbcXFct5WmB77vq7fryYe5lP
eCuWzEYLEul1OqkQnSuJ3VYYLsI3lWoV3i9JVgiDHU0RU7UFFAVYsQOmQqetmp3Q
BorP0Y6kf9/NyggtUoO6XhdenjdGqZRPQZbkB3+l4m7tVPasJKeE8hKAGyrRvWv9
HM49krTWeujoH62RiAIElRzIhOY2u8+5uLRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
topicbox.com; h=date:from:to:subject:in-reply-to:message-id
:references:mime-version:content-type; s=arcseal; t=1653250509;
bh=/N967Xt7/WAhc/w7RFS1OtkgChm5/m5s20BnZuSm+e0=; b=rFVynLGSI7/H
0Ex9UnMAjIzMYqA/YgW9gKD48SUdUoMzd/akBENqafD7XQIu2+/X0dV0qrGLcQ/a
dAl84TxwUYud6kOTYfBUohYo0NVe6FyvBjKPsPuMA0ivkb7lB1FOXIXM5P2wH9on
xHo8qzPRsunEzUh4/NuPmVM8l6Zu9zXJH9EGo109E/53qZVB73+w7k4XGWBqxrBh
ItUpehXkk73xGExlgAFhv9ELEw0REnIZIMPM6yi8j8JxwHbwmB33mUfEHZ0S+nbJ
HgmgKIEfyX08aZs9tHMm8kghk1LMihQam7AnOasdtLBvBbtZJLOvp9lC9gyhKO1s
iGOhSQDKtA==
ARC-Authentication-Results: i=1; tb-mx0.topicbox.com;
arc=none (no signatures found);
bimi=skipped (DMARC Policy is not at enforcement);
dkim=none (no signatures found);
dmarc=pass policy.published-domain-policy=none
policy.published-subdomain-policy=none policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=none,d=none,d.eval=none)
policy.policy-from=p header.from=sdf.org;
iprev=pass smtp.remote-ip=205.166.94.24 (mx.sdf.org);
spf=pass smtp.mailfrom=adr@SDF.ORG smtp.helo=mx.sdf.org;
x-aligned-from=pass (Address match);
x-me-sender=none;
x-ptr=pass smtp.helo=mx.sdf.org policy.ptr=mx.sdf.org;
x-return-mx=pass header.domain=sdf.org policy.is_org=yes
(MX Records found: mx.sdf.org);
x-return-mx=pass smtp.domain=sdf.org policy.is_org=yes
(MX Records found: mx.sdf.org);
x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384
smtp.bits=256/256;
x-vs=clean score=0 state=0
Received-SPF: pass
(sdf.org: 205.166.94.24 is authorized to use 'adr@SDF.ORG' in 'mfrom' identity
(mechanism 'ip4:205.166.94.0/24' matched))
receiver=tb-mx0.topicbox.com;
identity=mailfrom;
envelope-from="adr@SDF.ORG";
helo=mx.sdf.org;
client-ip=205.166.94.24
Date: Sun, 22 May 2022 20:15:06 +0000 (UTC)
From: adr <adr@SDF.ORG>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Aarch64 on labs|9legacy?
Topicbox-Policy-Reasoning: allow: sender is a member
Topicbox-Message-UUID: e46eee80-da0b-11ec-adcf-c9b62682de61
Archived-At:
<https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M811670166425640dec9b3703>
Reply-To: 9fans <9fans@9fans.net>
Topicbox-Delivery-ID:
2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:9e00e022-a139-11eb-b835-09bb272d11b0:M811670166425640dec9b3703:1:Z4keuj3Sp3SAP07yDiLSTalq3Zf3aK7I2o7HS1DTNX4
Has someone done something with aarch64 on labs|9legacy?
It's called arm64
Great.
Because with this 4 magical words I was supposed to find... what?
Where? What are you talking about? Where is this work on Bell Labs'
plan9 that I could find using the string "arm64" (which of course
I knew already from 9front, the only distribution with aarch64
support)? Even in Inferno there is no aarch64 support. Where are
this people publishing aarch64 work in the labs distribution that
I could fing using "arm64"? What are you talking about?
But now after all the useful interesting contribution to the list,
as usual, you have time to even express sarcasm.
You haven't help me to find anything, you don't have to do it, of
course, but then don't talk like you have done it.
A simple question, a fucking simple question and here we go with
the trolling and the bullshit, I'm done with this fucking list.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M811670166425640dec9b3703
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Sun May 22 16:19:07 EDT 2022
ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa
key
sha256) header.d=gmail.com header.i=@gmail.com header.b=k4xda904
header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
policy.published-domain-policy=none
policy.published-subdomain-policy=quarantine policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
policy.policy-from=p header.from=gmail.com; spf=pass
smtp.mailfrom=charles.forsyth@gmail.com smtp.helo=mail-ed1-f47.google.com;
x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
has been altered)) (Message modified while forwarding at Topicbox)
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=
topicbox.com; h=mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-type:list-help:list-id:list-post
:list-subscribe:reply-to:content-transfer-encoding
:list-unsubscribe; s=sysmsg-1; t=1653243653; bh=3v8WJ/52DweyF9NL
ZFQm5YbqIYQsmjcPRrONpSmTe+8=; b=E83iJnTrceRiVhDfzwDdgv52LRiNWlfL
Sfd+p3EmW+ug/0YqZvxmWYwPhLMVPnHUkk7OEIecHcB3ta8b3uUho82Mga+pjmUr
DSX210nTkiN71RAK0pt4mbSIhhZuBuO5IX8eURPx9DjWqln7810+YbvN64ZrFw2c
cZLot1LK4gE=
ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t=
1653243653; b=l/ozyn3qeutMUa74OLnpAoUuzYvgeQ+4exOCuQUWXylLvVIPJn
VIiitC2K0BRgYJOYMIUQhe5/XEcDstTScvzO7ueuNFzpCrP0iiQkYaCNbtwMKmLG
JGGTVeIc0Ew0M9SbmG93/EWvZnt6O3SgC7fiLEqA4ieGph1RkGJp9Afwk=
Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key
sha256) header.d=gmail.com header.i=@gmail.com header.b=k4xda904
header.a=rsa-sha256 header.s=20210112 x-bits=2048; dmarc=pass
policy.published-domain-policy=none
policy.published-subdomain-policy=quarantine policy.applied-disposition=none
policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none)
policy.policy-from=p header.from=gmail.com; spf=pass
smtp.mailfrom=charles.forsyth@gmail.com smtp.helo=mail-ed1-f47.google.com;
x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message
has been altered)) (Message modified while forwarding at Topicbox)
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t=
1653243526; b=E1H6DgoO3d07RN1sudWazT2X3mABsaW1kS7zIoeGOaKMwJBm6k
H42tNeqa4cwo85BOnX1Kujp7WzVVhuVvVsoCPQ3VIVDe6JNksv8AR9WOLm9njSBr
urE0X7I5AFlpMWUfME+vmfIearmLR4W3yhKIHCE55sbU+1F198cJJ3QIAdJgmz1b
IOxYNOqEvoDSCbiUoAzeTpIPSfFQA/acNX91/FEODF0dwomMz3ITyp3RMAo5ZqUB
DqPy5WpHechW2TstJnVmmuvAmSEQdNs6kKkN1bSDx6p6t/WrgDOPnir4ZU7T8o/6
igsrZfYq8p+wtYKV36eqUpbiSKmvCPLyVu9A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=
topicbox.com; h=mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-type; s=arcseal; t=1653243526;
bh=UCknuexKPA0ws0Hm6m4VHYnfP70T96m+ZcqoMf+avd8=; b=JE7gZ5B0Qq9H
1JIEO3qZYL1ZsYJUl8OgLTGzEyo2vwrfxkmECMnaLiZeM6edRqU8z4NcQ2hXWeqU
OmpffXNVDux9jpv/NHkK8rwyGD7EgGVtg9UXlpf36E4UPOB/iZ4PAmHB5Gnsz+cl
GGP4bx2JiEeME9YwqiRPe4n/ri1+zuXoDrTq9PZIpfGgL+iiipYtgSw1TJYtXLLK
e3MgMUF6LL9eSCOmLP6flCN4QQ6RsRIwMpqRN+GMrdq6I0RlWv7wU2X9+DtOYK5B
UWPstPv+l0aNwTqdoJxSpujpaeDQW/N/t06zmanuv7G4GvZ91gm2FHhcYy1ixkWT
P1NM8y4vsw==
ARC-Authentication-Results: i=1; tb-mx0.topicbox.com;
arc=none (no signatures found);
bimi=skipped (DMARC Policy is not at enforcement);
dkim=pass (2048-bit rsa key sha256) header.d=gmail.com
header.i=@gmail.com header.b=k4xda904 header.a=rsa-sha256
header.s=20210112 x-bits=2048;
dmarc=pass policy.published-domain-policy=none
policy.published-subdomain-policy=quarantine
policy.applied-disposition=none policy.evaluated-disposition=none
(p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p
header.from=gmail.com;
iprev=pass smtp.remote-ip=209.85.208.47 (mail-ed1-f47.google.com);
spf=pass smtp.mailfrom=charles.forsyth@gmail.com
smtp.helo=mail-ed1-f47.google.com;
x-aligned-from=pass (Address match);
x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net
header.i=@1e100.net header.b=jleXFMdD;
x-me-sender=none;
x-ptr=pass smtp.helo=mail-ed1-f47.google.com
policy.ptr=mail-ed1-f47.google.com;
x-return-mx=pass header.domain=gmail.com policy.is_org=yes
(MX Records found:
alt4.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com);
x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes
(MX Records found:
alt4.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com);
x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384
smtp.bits=256/256;
x-vs=clean score=0 state=0
Received-SPF: pass
(gmail.com ... _spf.google.com: Sender is authorized to use
'charles.forsyth@gmail.com' in 'mfrom' identity (mechanism
'include:_netblocks.google.com' matched))
receiver=tb-mx0.topicbox.com;
identity=mailfrom;
envelope-from="charles.forsyth@gmail.com";
helo=mail-ed1-f47.google.com;
client-ip=209.85.208.47
From: Charles Forsyth <charles.forsyth@gmail.com>
Date: Sun, 22 May 2022 19:18:34 +0100
Subject: Re: [9fans] Aarch64 on labs|9legacy?
To: 9fans <9fans@9fans.net>
Topicbox-Policy-Reasoning: allow: sender is a member
Topicbox-Message-UUID: a15cc8c0-d9fb-11ec-88fa-e2ec39de7134
Archived-At:
<https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M853e5a6fd4993355ec0b867f>
Reply-To: 9fans <9fans@9fans.net>
Topicbox-Delivery-ID:
2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:9e00e022-a139-11eb-b835-09bb272d11b0:M853e5a6fd4993355ec0b867f:1:6AJsPyaXfn5yRhnFAljVufhtFPdWC4Yu2dVN60cMBd4
You enquired about support for an architecture within Plan 9 on a Plan 9
list so the context was clear and I reply with the relevant architecture
string to help you locate it, but get a little lecture about Arm's naming
scheme (come to think of it, what are Thumb-1 and Thumb-2 called?). Next
time, I'll insist on the 27B/6.
On Fri, 20 May 2022, 22:27 adr, <adr@sdf.org> wrote:
> On Fri, 20 May 2022, Charles Forsyth wrote:
>
> > Date: Fri, 20 May 2022 21:34:05 +0100
> > From: Charles Forsyth <charles.forsyth@gmail.com>
> > Reply-To: 9fans <9fans@9fans.net>
> > To: 9fans <9fans@9fans.net>
> > Subject: Re: [9fans] Aarch64 on labs|9legacy?
> >
> > It's called arm64
>
> From
> https://developer.arm.com/documentation/den0024/a/Introduction?lang=en
>
> "AArch64 is the name used to describe the 64-bit execution state
> of the ARMv8 architecture. AArch32 describes the 32-bit execution
> state of the ARMv8 architecture, which is almost identical to ARMv7.
> GNU and Linux documentation (except for Redhat and Fedora distributions)
> sometimes refers to AArch64 as ARM64."
>
> I would agree that you could use the therm ARM64 as a synonym of
> Aarch64, but giving me just that response... It isn't even funny.
>
> adr.
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T000c7f7d66260ba3-M853e5a6fd4993355ec0b867f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Sat May 21 18:13:48 EDT 2022
0x30330000+0x0050 -> 0x00000000 0x30330000+0x0050 <- 0x00000000 # iomuxc for gpio1, mux mode==0 gpio 0x30200000+0x0004 -> 0x3f004210 0x30200000+0x0004 <- 0x3f004610 # IDR gpio1 io10 -> output 0x30200000+0x0000 -> 0x22004b90 0x30200000+0x0000 <- 0x22004f90 # set gpio1 io10 high 0x30670000+0x0008 <- 0x00000000 # pwm idr 0 0x30670000+0x0000 <- 0x01c20000 # pwm cr 0x30670000+0x000c <- 0x00000000 # pwm sar (dity cycles) 0x30670000+0x0010 <- 0x0000ffff # pwm pr (period) 0x30670000+0x0000 -> 0x01c20000 0x30670000+0x0000 <- 0x01c20001 # pwm set enbale 0x30670000+0x000c <- 0x0000ffff # pwm change duty cycle 0x30670000+0x000c <- 0x00007fff # ... 0x30670000+0x000c <- 0x00003fff # ...
Thu May 19 12:59:43 EDT 2022
## Python 3 provider (optional)
- INFO: Using: g:python3_host_prog = "$HOME/.config/nvim/py37/bin/python"
- INFO: Executable:
<REDACTED_BUT_DEFINITELY_VALID>/.config/nvim/py37/bin/python
- INFO: Python version: 3.7.5
- INFO: pynvim version: 0.4.3
- OK: Latest pynvim is installed.
Thu May 19 12:34:21 EDT 2022
function <SNR>53_filetype_changed[4]..remote#define#CommandBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[12]..provider#Poll, line 6 Vim(let):E475: Invalid value for argument cmd: '' is not executable Error detected while processing function <SNR>53_filetype_changed[4]..remote#define#CommandBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[12]..provider#Poll: line 17: E605: Exception not caught: Failed to load python3 host. You can try to see what happened by starting nvim with $NVIM_PYTHON_LOG_FILE set and opening the generated log file. Also, the host stderr is available in messages. Error detected while processing function <SNR>53_filetype_changed[4]..remote#define#CommandBootstrap[1]..remote#host#Require: line 10: E171: Missing :endif Error detected while processing function <SNR>53_filetype_changed: line 4: E171: Missing :endif
Wed May 18 16:50:19 EDT 2022
#Colorset Colorset 0 fg black, bg #cbdcca, hi white, sh #777777 Colorset 1 fg #777777, bg #cbdcca, hi white, sh black Colorset 2 fg black, bg #cbdcca, hi white, sh black Colorset 3 bg black, hi black, sh black #Global style settings Style * !ResizeOpaque, SnapAttraction 15 SameType ScreenAll, SnapGrid Style * BorderColorset 3, HilightBorderColorset 3, !Handles Style * BorderWidth 1, HandleWidth 1, !MWMButtons, MwmBorder Style * Colorset 1, HilightColorset 2 Style * !Icon #Window Decor TitleStyle Centered Height 20 -- Flat AddTitleStyle Vector 3 0x100@1 0x0@1 100x0@1 AddTitleStyle Vector 3 100-1px0@0 100-1px100-1p@0 0x100-1p@0 BorderStyle Simple ButtonStyle All Simple ButtonStyle 1 - MwmDecorMenu ButtonStyle 4 - MwmDecorMax ButtonStyle 6 - MwmDecorMin # Title Buttons Mouse 1 1 A Menu MenuWindowOps Delete Mouse 1 2 A Close Mouse 1 4 A Maximize 100 100 Mouse 2 4 A Maximize 0 100 Mouse 3 4 A Maximize 100 0 Mouse 1 6 A Iconify
Wed May 18 04:51:16 EDT 2022
#include <u.h>
#include <libc.h>
#include <draw.h>
#include <event.h>
char* options1[] = {"Middle Click", "", "Paste", "Snarf", "Exit", 0};
char* options2[] = {"Right Click", "", "Option3", "Option4", "Exit", 0};
Menu middlemenu = {options1};
Menu rightmenu = {options2};
void
eresized(int new)
{
if(new&& getwindow(display, Refnone) < 0)
sysfatal("can't reattach to window");
}
void
dopaste(void)
{
int f;
if((f = open("/dev/snarf", OREAD)) >= 0) {
char body[30];
read(f, body, 30);
print("Paste: %s\n", body);
close(f);
}
}
void
dosnarf(void)
{
int f;
if((f = open("/dev/snarf", OWRITE)) >= 0) {
char* body = "some text";
write(f, body, strlen(body));
print("Snarf: %s\n", body);
close(f);
}
}
void
main(int argc, char* argv[])
{
USED(argc, argv);
Event ev;
int e;
initdraw(0, 0, "Example: Menu");
eresized(0);
einit(Emouse);
/* Main event loop */
for(;;) {
e = event(&ev);
/* Middle Click */
if((e == Emouse) && (ev.mouse.buttons & 3)) {
if(emenuhit(2, &ev.mouse, &middlemenu) == 2)
dopaste();
if(emenuhit(2, &ev.mouse, &middlemenu) == 3)
dosnarf();
if(emenuhit(2, &ev.mouse, &middlemenu) == 4)
exits(nil);
}
/* Right Click */
else if((e == Emouse) && (ev.mouse.buttons & 4)) {
if(emenuhit(3, &ev.mouse, &rightmenu) == 2)
print("Pressed Option 3\n");
if(emenuhit(3, &ev.mouse, &rightmenu) == 3)
print("Pressed Option 4\n");
if(emenuhit(3, &ev.mouse, &rightmenu) == 4)
exits(nil);
}
}
}