doas called multiple times hangs
Hi,
Calling 'doas' in a loop makes the machine hang.
I guess this is not an expected behavior.
It can be checked by executing the following simple bash script:
for i in {0..2}
do
doas ls some_dir
done
I have run it on three different machines and the result is the same on
each of them. After about 9000 iterations the entire machine hangs.
Executing the script without 'doas' works fine.
Re: doas called multiple times hangs
This is -stable 6.4.
doas.conf:
permit nopass myuser as root
On Sun, 20 Jan 2019 at 11:50, Hiltjo Posthuma
wrote:
> On Sun, Jan 20, 2019 at 11:15:38AM +0100, Dariusz Sendkowski wrote:
> > Hi,
> >
> > Calling 'doas' in a loop makes the machine hang.
> > I guess this is not an expected behavior.
> > It can be checked by executing the following simple bash script:
> >
> > for i in {0..2}
> > do
> > doas ls some_dir
> > done
> >
> > I have run it on three different machines and the result is the same on
> > each of them. After about 9000 iterations the entire machine hangs.
> > Executing the script without 'doas' works fine.
>
> Hi,
>
> Just tested, but no issue here on -current.
>
> What is your doas.conf contents and OpenBSD version / dmesg?
>
> --
> Kind regards,
> Hiltjo
>
Re: doas called multiple times hangs
On Sun, Jan 20, 2019 at 11:15:38AM +0100, Dariusz Sendkowski wrote:
> Hi,
>
> Calling 'doas' in a loop makes the machine hang.
> I guess this is not an expected behavior.
> It can be checked by executing the following simple bash script:
>
> for i in {0..2}
> do
> doas ls some_dir
> done
>
> I have run it on three different machines and the result is the same on
> each of them. After about 9000 iterations the entire machine hangs.
> Executing the script without 'doas' works fine.
Hi,
Just tested, but no issue here on -current.
What is your doas.conf contents and OpenBSD version / dmesg?
--
Kind regards,
Hiltjo
Re: Problems trying to format currency with python
Hi Luca,
Luca Franchini wrote on Sun, Jan 20, 2019 at 03:41:46PM +0100:
> I got an error while running this:
>
> amidatacyber730:~$ python3.6
> Python 3.6.6 (default, Oct 11 2018, 12:39:19)
> [GCC 4.2.1 Compatible OpenBSD Clang 6.0.0 (tags/RELEASE_600/final)] on o
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import locale
> >>> locale.setlocale(locale.LC_ALL, "it_IT.UTF-8")
> 'it_IT.UTF-8'
> >>> locale.currency(6.4)
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/local/lib/python3.6/locale.py", line 262, in currency
> raise ValueError("Currency formatting is not possible using "
> ValueError: Currency formatting is not possible using the 'C' locale.
The error message that Python is producing is confusing.
Here is what the code in the Python library actually does:
/usr/local/lib/python3.6/locale.py:
def currency(val, symbol=True, grouping=False, international=False):
conv = localeconv()
# check for illegal values
digits = conv[international and 'int_frac_digits' or 'frac_digits']
if digits == 127:
raise ValueError("Currency formatting is not possible using "
"the 'C' locale.")
OpenBSD intentionally does not implement any LC_MONETARY or strfmon(3)
functionality because we believe that such functionality does not
belong in the C library but should instead be implemented in
specialized support libraries for user interface design.
Consequently, LC_MONETARY is completely ignored by the OpenBSD base
system and localeconv(3) always returns the values that POSIX
specifies for the C locale, no matter what the user asks for.
You might wish to report upstream (to the Python project) that the
error message is misleading. It is true that this message can occur
when the user selected LC_MONETARY=C. But it can also happen when the
operating system does not implement LC_MONETARY support at all.
Yours,
Ingo
Re: Raspberry Pi support in 6.4
> On January 19, 2019 at 11:34 PM Karel Gardas wrote: > Well, with RPiX you completely missed the target I'm afriad. If I'm > correct, then whole SoC is booted on the side of video processor which > loads some blobs into it, run ThreadX OS and then boots ARMv8 > bootloader on ARM core. There have been some attempt to replace ThreadX > and binary blob on RPiX, but so far IIRC unsuccessful. I did indeed miss the target, and what you say is largely consistent with my own further research. The upside of the RPi is it (seems) to be a stateless device outside the data stored on the SD card -- there seems to be no other firmware/flash devices that could store malware. While the RPi does this for pedagogical rather than security reasons (they wanted it to be un-brickable) some security researchers (Rutkowska) recommend statelessness as a partial mitigation strategy for the security risks inherent in blobs (to stop them being used to persist malware outside the OS). Unfortunately it looks like there are no current production mainstream devices which do any better (unless OpenBSD has figured out how to replace the Pine64 firmware), leaving niche devices based on e.g OpenPOWER and RISC V. Neither of which fit in hand luggage :/
Re: Raspberry Pi support in 6.4
> On January 19, 2019 at 6:17 PM Mihai Popescu wrote: > Since it looks to me that you missed the point, here is it: most > people on this list, devs mostly are not on vacation ... > Ask precisely! Ok, thanks for pointing that out.
Problems trying to format currency with python
Hi all,
I got an error while running this:
amidatacyber730:~$ python3.6
Python 3.6.6 (default, Oct 11 2018, 12:39:19)
[GCC 4.2.1 Compatible OpenBSD Clang 6.0.0 (tags/RELEASE_600/final)] on o
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "it_IT.UTF-8")
'it_IT.UTF-8'
>>> locale.currency(6.4)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.6/locale.py", line 262, in currency
raise ValueError("Currency formatting is not possible using "
ValueError: Currency formatting is not possible using the 'C' locale.
>>> quit()
amidatacyber730:~$ locale -a | grep IT
it_IT.UTF-8
amidatacyber730:~$ uname -mrsv
OpenBSD 6.4 GENERIC.MP#3 amd64
Thank you,
Luca
Re: Raspberry Pi support in 6.4
On Sun, Jan 20, 2019, 21:53 Unfortunately it looks like there are no current production mainstream > devices which do any better (unless OpenBSD has figured out how to replace > the Pine64 firmware), leaving niche devices based on e.g OpenPOWER and RISC > V. > > Neither of which fit in hand luggage :/ > The SiFive FU540 runs FreeBSD. https://www.sifive.com/boards/hifive-unleashed https://fosdem.org/2019/schedule/event/testing_freebsd_risc_v5/ Thanks. Regards, Dinesh >
Re: APU2 and Spectre
If someone is interested: https://github.com/kolargol/apu2_firmware of course for testing bins, OpenBSD reports IBPB: cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,IBPB,XSAVEOPT On 21:11 Mon 10 Sep, Zbyszek Żółkiewski wrote: > > > Wiadomość napisana przez Consus < con...@ftml.net > w dniu 25.08.2018, o godz. 17:08: > > > > Seems like APU2 board is vulnerable to Spectre: > > seems there is microcode update with mitigations but looks like none want to > claim where that microcode comes from: > > https://github.com/pcengines/apu2-documentation/issues/75 > > did someone try to load it from obsd? is it possible? >> There is an unofficial binary with unknown origin. Seems like AMD have >> sent microcode updates to some motherboard manufacturers, but there is >> no hard proof though.
Re: doas called multiple times hangs
Dariusz Sendkowski wrote:
> I investigated the problem a little more and found, that when there is a
> non-existent directory entry in my PATH, the problem occurs. If all of the
> directories from my PATH exist, then it works fine.
To help isolate the problem, if you disable unveil, does it work?
Index: doas.c
===
RCS file: /cvs/src/usr.bin/doas/doas.c,v
retrieving revision 1.74
diff -u -p -r1.74 doas.c
--- doas.c 17 Jan 2019 05:35:35 - 1.74
+++ doas.c 20 Jan 2019 21:30:55 -
@@ -409,8 +409,6 @@ main(int argc, char **argv)
if (setenv("PATH", safepath, 1) == -1)
err(1, "failed to set PATH '%s'", safepath);
}
- if (unveilcommands(getenv("PATH"), cmd) == 0)
- goto fail;
if (pledge("stdio rpath getpw exec id", NULL) == -1)
err(1, "pledge");
Re: smtpd - help needed tranlsating to new virtual map syntax
As it turns out, no, that doesn't work.
Trying to fix up broken sender mail domain-parts only simply gets me a "5.2.4
Mailing list expansion problem" error, with no debug output to suggest why.
In this test case, my translations map had:
@bad.athompso.net @good.athompso.net
in it. Obviously, this is a test setup :).
Smtpd.conf itself consisted of:
listen on all received-auth
smtp max-message-size 100M
table translations file:/etc/mail/translations # ORIG->NEW
mappings
table allowed-hosts file:/etc/mail/allowed-hosts# Who can
connect? (bare IP addresses or CIDR subnets)
action translate lmtp "/var/run/lmtp.sock" virtual
# 1st pass on allowed rewrite mail
action forward forward-only
# and now it's not our problem anymore
match for any from local action forward # 2nd pass for
reinjected mail, this time just forward it
match for any from src action translate # inbound mail
- hand it to LMTP, translating as we go
A cursory glance at the source code (yikes, it's been a long time since I was a
programmer) suggests that virtual now only works on recipients, not senders.
Which is too bad for me, as that means I'll have to switch at least one box to
use Postfix.
I'm not convinced the new smtpd.conf grammar improves anything at all, but I
assume it must help someone or it wouldn't have changed... but I believe my use
case got thrown out with the bathwater, so to speak. Oh, well. :-(
(If anyone cares, the bad sender addresses are mostly alerts coming from older
Sun ALOMs and at least one Lexmark printer that also sends email with broken
From addresses.)
-Adam
-Original Message-
From: owner-m...@openbsd.org On Behalf Of Adam Thompson
Sent: Wednesday, January 16, 2019 8:26 AM
To: 'Edgar Pettijohn' ; misc@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
As I said, I haven't tried anything yet as I don't want to break a working
system, and I don't have a good way to test this in parallel right now.
The manpage says "The local delivery methods support additional options: [...]
virtual" without specifying which delivery methods are "local". My assumption
was that only "mbox" and "mda" were local, as lmtp can, and often does, point
to another server.
Some brief experiments with a VM only got me syntax errors, so I didn't pursue
that very thoroughly before asking for clarification.
-Adam
-Original Message-
From: Edgar Pettijohn
Sent: Wednesday, January 16, 2019 8:12 AM
To: Adam Thompson ; misc@openbsd.org
Subject: Re: smtpd - help needed tranlsating to new virtual map syntax
It would be helpful if you show what you have tried.
Should be as simple as:
action "relay-01" lmtp /var/run/lmtp.sock virtual
match from src action "relay-01"
Edgar
On Jan 16, 2019 7:37 AM, Adam Thompson wrote:
>
> [Cross-posting here before I give up and switch to Postfix -Adam]
>
>
> I have an old instance that uses smtpd's virtual to rewrite *sender*
> addresses.
> Reading the 6.4-STABLE version of the smtpd.conf(5) manpage, I can't see how
> to accomplish my goal any more - it looks impossible.
>
> I don't want to upgrade a working mail relay server to something that might
> be broken, so I'm seeking assistance first.
>
> The purpose of this system is purely to relay mail from internal,
> semi-broken-ish systems out to our Office365 tenant, but I need to clean up
> bogus MAIL FROM / "From:" headers first, lest they be flagged as spam.
>
> In general, I think I'm asking how to use virtual with the "relay"
> action in the new syntax - the manual tells me this is impossible!?
>
> Thanks,
> -Adam
>
>
> Old smtpd.conf:
>
> ===start===
> listen on 0.0.0.0
> listen on ::
> table aliases db:/etc/opensmtpd/aliases.db table vmap
> db:/etc/opensmtpd/vmap.db table localnets { 192.168.10.0/24,
> 192.168.100.0/24, 192.168.157.0/24, 192.168.158.0/24,
> 192.168.101.0/24, 10.158.0.0/16 } accept from local
> for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com hostname remote.XXX.ca
> accept from source 192.168.158.63 for domain 192.168.158.63 virtual
> deliver to lmtp localhost:25 accept from source 192.168.100.63
> for domain 192.168.100.63 virtual deliver to lmtp localhost:25
> accept from source 192.168.158.63 for anyrelay via
> smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca hostname
> remote.XXX.ca accept from source 192.168.100.63 for any
> relay via smtp://XXX-ca.mail.protection.outlook.com as sys...@xxx.ca
> hostname remote.XXX.ca accept from source for any
>
> relay via smtp://XXX-ca.mail.protection.outlook.com hostname
> remote.XXX.ca ===end===
>
> old vmap:
>
> ===start===
> ilom-alert@192.168.100.63: sys...@xxx.ca
> sys...@xxx.ca: sys...@xxx.ca
> sys...@ad.xxx.ca:
Re: smtpd - help needed tranlsating to new virtual map syntax
I found the "-T" (trace) flag to smtpd(8), and it gives me this, which AFAICT confirms my suspicions: [...] rule #2 matched: match from src allowed-hosts for any => translate lookup: lookup "athom...@athompso.net" as ALIAS in table static:translations -> 0 lookup: lookup "athompso" as ALIAS in table static:translations -> 0 lookup: lookup "@athompso.net" as ALIAS in table static:translations -> 0 lookup: lookup "@" as ALIAS in table static:translations -> 0 expand: lka_expand: no aliases for virtual mproc: lka -> pony : 53 IMSG_SMTP_EXPAND_RCPT expand: 0x154201b89018: clearing expand tree imsg: pony <- lka: IMSG_SMTP_EXPAND_RCPT (len=53) smtp: 0x1127a72e6000: >>> 524 5.2.4 Mailing list expansion problem [...] complete output attached below, I've changed to @old.athompso.net and @new.athompso.net during testing since the last email. On the sending side, from another host (listed in ), I'm running: swaks --to athom...@athompso.net --from athom...@old.athompso.net --server which faithfully reports the 5.2.4 error. I'm slightly disappointed, I still like OpenSMTPd's concise configuration syntax. Postfix could still rewrite source addresses last time I checked, I hope it's still there - I do NOT want to run sendmail, thank you very much. -Adam Smtpd(8) trace output including invocation: ===from here to end of message=== bhs# smtpd -d -T all -v -d debug: init ssl-tree debug: init ca-tree debug: init ssl-tree debug: using "fs" queue backend debug: using "ramqueue" scheduler backend debug: using "ram" stat backend info: OpenSMTPD 6.4.0 starting debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ca-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ssl-tree debug: init ca-tree debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: using "fs" queue backend debug: init ssl-tree debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "ramqueue" scheduler backend debug: using "fs" queue backend debug: using "ram" stat backend setup_peer: klondike -> control[63932] fd=4 setup_peer: klondike -> pony express[40666] fd=5 setup_done: ca[35575] done debug: using "ram" stat backend setup_peer: control -> klondike[35575] fd=4 setup_peer: control -> lookup[49698] fd=5 setup_peer: control -> pony express[40666] fd=6 setup_peer: control -> queue[21502] fd=7 setup_peer: control -> scheduler[14152] fd=8 setup_done: control[63932] done debug: using "ram" stat backend setup_peer: lookup -> control[63932] fd=4 setup_peer: lookup -> pony express[40666] fd=5 setup_peer: lookup -> queue[21502] fd=6 setup_done: lka[49698] done debug: using "ram" stat backend setup_peer: pony express -> control[63932] fd=4 setup_peer: pony express -> klondike[35575] fd=5 setup_peer: pony express -> lookup[49698] fd=6 setup_peer: pony express -> queue[21502] fd=7 setup_done: pony[40666] done debug: using "ram" stat backend setup_peer: queue -> control[63932] fd=4 setup_peer: queue -> pony express[40666] fd=5 setup_peer: queue -> lookup[49698] fd=6 setup_peer: queue -> scheduler[14152] fd=7 setup_done: queue[21502] done debug: using "ramqueue" scheduler backend debug: using "ram" stat backend setup_peer: scheduler -> control[63932] fd=4 setup_peer: scheduler -> queue[21502] fd=5 setup_done: scheduler[14152] done smtpd: setup done mproc: parent -> control: enabled mproc: parent -> lka: enabled mproc: parent -> queue: enabled mproc: parent -> ca: enabled mproc: parent -> pony: enabled debug: parent_send_config_ruleset: reloading mproc: parent -> lka : 0 IMSG_CONF_START mproc: parent -> lka : 0 IMSG_CONF_END debug: parent_send_config: configuring pony process mproc: parent -> pony : 0 IMSG_CONF_START mproc: parent -> pony : 0 IMSG_CONF_END debug: parent_send_config: configuring ca process mproc: parent -> ca : 0 IMSG_CONF_START mproc: parent -> ca : 0 IMSG_CONF_END setup_proc: klondike done setup_proc: control done setup_proc: lookup done setup_proc: pony express done setup_proc: queue done setup_proc: scheduler done mproc: ca -> control: enabled debug: bounce warning after 4h mproc: ca -> parent: enabled mproc: ca -> pony: enabled mproc: ca -> pony: disabled mproc: pony -> parent: enabled mproc: scheduler -> control: enabled imsg: ca <- parent: IMSG_CONF_START (len=0) mproc: lka -> parent: enabled mproc: pony -> queue: enabled mproc: scheduler -> queue: enabled scheduler: getting batch: mask=0x3f, count=10 debug: /--- ramqueue: scheduler_ram_batch() debug: \--- scheduler: got r=0, delay=-1, count=10 scheduler: sleeping imsg:
Re: doas called multiple times hangs
Yes, it does.
I extracted 'unveilcommands' function from doas.c and put it into a
standalone program to run it.
It turned out the result was the same as in doas command. When I disable
unveil, then it works fine.
niedz., 20 sty 2019 o 22:31 Ted Unangst napisał(a):
> Dariusz Sendkowski wrote:
> > I investigated the problem a little more and found, that when there is a
> > non-existent directory entry in my PATH, the problem occurs. If all of
> the
> > directories from my PATH exist, then it works fine.
>
> To help isolate the problem, if you disable unveil, does it work?
>
>
> Index: doas.c
> ===
> RCS file: /cvs/src/usr.bin/doas/doas.c,v
> retrieving revision 1.74
> diff -u -p -r1.74 doas.c
> --- doas.c 17 Jan 2019 05:35:35 - 1.74
> +++ doas.c 20 Jan 2019 21:30:55 -
> @@ -409,8 +409,6 @@ main(int argc, char **argv)
> if (setenv("PATH", safepath, 1) == -1)
> err(1, "failed to set PATH '%s'", safepath);
> }
> - if (unveilcommands(getenv("PATH"), cmd) == 0)
> - goto fail;
>
> if (pledge("stdio rpath getpw exec id", NULL) == -1)
> err(1, "pledge");
>
Re: doas called multiple times hangs
I investigated the problem a little more and found, that when there is a
non-existent directory entry in my PATH, the problem occurs. If all of the
directories from my PATH exist, then it works fine.
niedz., 20 sty 2019 o 12:00 Dariusz Sendkowski
napisał(a):
> This is -stable 6.4.
> doas.conf:
> permit nopass myuser as root
>
>
>
>
> On Sun, 20 Jan 2019 at 11:50, Hiltjo Posthuma
> wrote:
>
>> On Sun, Jan 20, 2019 at 11:15:38AM +0100, Dariusz Sendkowski wrote:
>> > Hi,
>> >
>> > Calling 'doas' in a loop makes the machine hang.
>> > I guess this is not an expected behavior.
>> > It can be checked by executing the following simple bash script:
>> >
>> > for i in {0..2}
>> > do
>> > doas ls some_dir
>> > done
>> >
>> > I have run it on three different machines and the result is the same on
>> > each of them. After about 9000 iterations the entire machine hangs.
>> > Executing the script without 'doas' works fine.
>>
>> Hi,
>>
>> Just tested, but no issue here on -current.
>>
>> What is your doas.conf contents and OpenBSD version / dmesg?
>>
>> --
>> Kind regards,
>> Hiltjo
>>
>
New York Times: Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers
Subject/Topic: New York Times: Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers This New York Times newspaper article is very welcome and being held dear by millions of Targeted Individuals (TIs) all over the world, including Mr. Turritopsis Dohrnii Teo En Ming, who is based in Singapore. New York Times Article: Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Author: William J. Broad is a science journalist and senior writer. He joined The Times in 1983, and has shared two Pulitzer Prizes with his colleagues, as well as an Emmy Award and a DuPont Award. @WilliamJBroad Date Published: 1st September 2018 (Today is 19 January 2019 Saturday) Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html Snippets from the New York Times newspaper article: Doctors and scientists say microwave strikes may have caused sonic delusions and very real brain damage among embassy staff and family members. During the Cold War, Washington feared that Moscow was seeking to turn microwave radiation into covert weapons of mind control. More recently, the American military itself sought to develop microwave arms that could invisibly beam painfully loud booms and even spoken words into people’s heads. The aims were to disable attackers and wage psychological warfare. Now, doctors and scientists say such unconventional weapons may have caused the baffling symptoms and ailments that, starting in late 2016, hit more than three dozen American diplomats and family members in Cuba and China. The Cuban incidents resulted in a diplomatic rupture between Havana and Washington. But Douglas H. Smith, the study’s lead author and director of the Center for Brain Injury and Repair at the University of Pennsylvania, said in a recent interview that microwaves were now considered a main suspect and that the team was increasingly sure the diplomats had suffered brain injury. In particular, a growing number of analysts cite an eerie phenomenon known as the Frey effect, named after Allan H. Frey, an American scientist. Long ago, he found that microwaves can trick the brain into perceiving what seem to be ordinary sounds. The false sensations, the experts say, may account for a defining symptom of the diplomatic incidents — the perception of loud noises, including ringing, buzzing and grinding. Initially, experts cited those symptoms as evidence of stealthy attacks with sonic weapons. Members of Jason, a secretive group of elite scientists that helps the federal government assess new threats to national security, say it has been scrutinizing the diplomatic mystery this summer and weighing possible explanations, including microwaves. The microwave idea teems with unanswered questions. Who fired the beams? The Russian government? The Cuban government? A rogue Cuban faction sympathetic to Moscow? And, if so, where did the attackers get the unconventional arms? At his home outside Washington, Mr. Frey, the scientist who uncovered the neural phenomenon, said federal investigators have questioned him on the diplomatic riddle and that microwave radiation is considered a possible cause. Mr. Frey, now 83, has traveled widely and long served as a contractor and a consultant to a number of federal agencies. He speculated that Cubans aligned with Russia, the nation’s longtime ally, might have launched microwave strikes in attempts to undermine developing ties between Cuba and the United States. The dimensions of the human head, scientists say, make it a fairly good antenna for picking up microwave signals. Mr. Frey, a biologist, said he stumbled on the acoustic effect in 1960 while working for General Electric’s Advanced Electronics Center at Cornell University. A man who measured radar signals at a nearby G.E. facility came up to him at a meeting and confided that he could hear the beam’s pulses — zip, zip, zip. Intrigued, Mr. Frey traveled to the man’s workplace in Syracuse and positioned himself in a radar beam. “Lo,” he recalled, “I could hear it, too.” Mr. Frey’s resulting papers — reporting that even deaf people could hear the false sounds — founded a new field of study on radiation’s neural impacts. Mr. Frey’s first paper, in 1961, reported that power densities 160 times lower than “the standard maximum safe level for continuous exposure” could induce the sonic delusions. Investigators raced to confirm and extend Mr. Frey’s findings. At first they named the phenomenon after him, but eventually called it the microwave auditory effect and, in time, more generally, radio-frequency hearing. Moscow was so intrigued by the prospect of mind control that it adopted a special terminology for the overall class of envisioned arms, calling them psychophysical and psychotronic. Soviet research on microwaves for “internal sound perception,” the Defense Intelligence Agency warned in 1976, showed great promise for “disrupting the behavior patterns of military or diplomatic personnel.”
Re: doas called multiple times hangs
Dariusz Sendkowski wrote: > Yes, it does. > > I extracted 'unveilcommands' function from doas.c and put it into a > standalone program to run it. > It turned out the result was the same as in doas command. When I disable > unveil, then it works fine. This diff should fix the problem. Index: kern_unveil.c === RCS file: /cvs/src/sys/kern/kern_unveil.c,v retrieving revision 1.22 diff -u -p -r1.22 kern_unveil.c --- kern_unveil.c 17 Jan 2019 03:26:19 - 1.22 +++ kern_unveil.c 21 Jan 2019 01:31:23 - @@ -630,8 +630,6 @@ unveil_add(struct proc *p, struct nameid done: if (ret == 0) unveil_add_traversed_vnodes(p, ndp); - unveil_free_traversed_vnodes(ndp); - pool_put(_pool, ndp->ni_cnd.cn_pnbuf); return ret; } Index: vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.310 diff -u -p -r1.310 vfs_syscalls.c --- vfs_syscalls.c 3 Jan 2019 21:52:31 - 1.310 +++ vfs_syscalls.c 21 Jan 2019 01:29:38 - @@ -92,6 +92,7 @@ int dofutimens(struct proc *, int, struc int dounmount_leaf(struct mount *, int, struct proc *); int unveil_add(struct proc *, struct nameidata *, const char *); void unveil_removevnode(struct vnode *vp); +void unveil_free_traversed_vnodes(struct nameidata *); ssize_t unveil_find_cover(struct vnode *, struct proc *); struct unveil *unveil_lookup(struct vnode *, struct proc *, ssize_t *); @@ -948,6 +949,8 @@ sys_unveil(struct proc *p, void *v, regi vrele(nd.ni_vp); if (nd.ni_dvp && nd.ni_dvp != nd.ni_vp) vrele(nd.ni_dvp); + unveil_free_traversed_vnodes(); + pool_put(_pool, nd.ni_cnd.cn_pnbuf); return (error); }
Re: Raspberry Pi support in 6.4
> The SiFive FU540 runs FreeBSD. > > https://www.sifive.com/boards/hifive-unleashed > > https://fosdem.org/2019/schedule/event/testing_freebsd_risc_v5/ Very cool!
Re: doas called multiple times hangs
Ted Unangst wrote: > Dariusz Sendkowski wrote: > > Yes, it does. > > > > I extracted 'unveilcommands' function from doas.c and put it into a > > standalone program to run it. > > It turned out the result was the same as in doas command. When I disable > > unveil, then it works fine. > > This diff should fix the problem. Actually, miscalculation. This is a better diff. Sorry for the trouble. Against current, but should be adaptable to stable. Index: vfs_syscalls.c === RCS file: /cvs/src/sys/kern/vfs_syscalls.c,v retrieving revision 1.310 diff -u -p -r1.310 vfs_syscalls.c --- vfs_syscalls.c 3 Jan 2019 21:52:31 - 1.310 +++ vfs_syscalls.c 21 Jan 2019 04:57:17 - @@ -92,6 +92,7 @@ int dofutimens(struct proc *, int, struc int dounmount_leaf(struct mount *, int, struct proc *); int unveil_add(struct proc *, struct nameidata *, const char *); void unveil_removevnode(struct vnode *vp); +void unveil_free_traversed_vnodes(struct nameidata *); ssize_t unveil_find_cover(struct vnode *, struct proc *); struct unveil *unveil_lookup(struct vnode *, struct proc *, ssize_t *); @@ -911,7 +912,7 @@ sys_unveil(struct proc *p, void *v, regi nd.ni_pledge = PLEDGE_UNVEIL; if ((error = namei()) != 0) - return (error); + goto end; /* * XXX Any access to the file or directory will allow us to @@ -948,6 +949,10 @@ sys_unveil(struct proc *p, void *v, regi vrele(nd.ni_vp); if (nd.ni_dvp && nd.ni_dvp != nd.ni_vp) vrele(nd.ni_dvp); + + pool_put(_pool, nd.ni_cnd.cn_pnbuf); +end: + unveil_free_traversed_vnodes(); return (error); } Index: kern_unveil.c === RCS file: /cvs/src/sys/kern/kern_unveil.c,v retrieving revision 1.22 diff -u -p -r1.22 kern_unveil.c --- kern_unveil.c 17 Jan 2019 03:26:19 - 1.22 +++ kern_unveil.c 21 Jan 2019 05:01:26 - @@ -630,8 +630,6 @@ unveil_add(struct proc *p, struct nameid done: if (ret == 0) unveil_add_traversed_vnodes(p, ndp); - unveil_free_traversed_vnodes(ndp); - pool_put(_pool, ndp->ni_cnd.cn_pnbuf); return ret; }
