Re: vmd(8): slight NS8250 fix
On Wed, May 22, 2019 at 08:05:50PM -0500, Katherine Rohl wrote:
> Hi,
>
> Adjusted NS8250 behavior in vmd(8) so it gets detected as an 8250 and not a
> 16450 by OpenBSD’s boot process. Also generalized some of the COM1-specific
> I/O address definitions to support adding COM2 (and COM3, and COM4…) in the
> future.
>
> Tested by logging into my VM with the virtual serial console and reinstalling
> 6.5, everything was fine. The boot process detected an NS8250.
>
Thanks for the vmd diff.
Please test with various Linux guests also. I added the scratch reg to make
this like an 8250A, IIRC, to support Linux guests. And you'll need to test
with a few, Alpine, Ubuntu, Centos, etc, as they all had different
behaviour. If those all work then we can get this in.
-ml
> Index: ns8250.c
> ===
> RCS file: /cvs/src/usr.sbin/vmd/ns8250.c,v
> retrieving revision 1.20
> diff -u -p -u -r1.20 ns8250.c
> --- ns8250.c 11 Mar 2019 17:08:52 - 1.20
> +++ ns8250.c 23 May 2019 00:52:15 -
> @@ -74,6 +74,7 @@ ns8250_init(int fd, uint32_t vmid)
> }
> com1_dev.fd = fd;
> com1_dev.irq = 4;
> + com1_dev.portid = NS8250_COM1;
> com1_dev.rcv_pending = 0;
> com1_dev.vmid = vmid;
> com1_dev.byte_out = 0;
> @@ -509,10 +510,10 @@ vcpu_process_com_scr(struct vm_exit *vei
> /*
>* vei_dir == VEI_DIR_OUT : out instruction
>*
> - * Write to SCR
> + * The 8250 does not have a scratch register.
>*/
> if (vei->vei.vei_dir == VEI_DIR_OUT) {
> - com1_dev.regs.scr = vei->vei.vei_data;
> + com1_dev.regs.scr = 0xFF;
> } else {
> /*
>* vei_dir == VEI_DIR_IN : in instruction
> @@ -647,6 +648,7 @@ ns8250_restore(int fd, int con_fd, uint3
> }
> com1_dev.fd = con_fd;
> com1_dev.irq = 4;
> + com1_dev.portid = NS8250_COM1;
> com1_dev.rcv_pending = 0;
> com1_dev.vmid = vmid;
> com1_dev.byte_out = 0;
> Index: ns8250.h
> ===
> RCS file: /cvs/src/usr.sbin/vmd/ns8250.h,v
> retrieving revision 1.7
> diff -u -p -u -r1.7 ns8250.h
> --- ns8250.h 11 Mar 2019 17:08:52 - 1.7
> +++ ns8250.h 23 May 2019 00:52:15 -
> @@ -18,14 +18,30 @@
> /*
> * Emulated 8250 UART
> */
> -#define COM1_DATA0x3f8
> -#define COM1_IER 0x3f9
> -#define COM1_IIR 0x3fa
> -#define COM1_LCR 0x3fb
> -#define COM1_MCR 0x3fc
> -#define COM1_LSR 0x3fd
> -#define COM1_MSR 0x3fe
> -#define COM1_SCR 0x3ff
> +#define COM1_BASE 0x3f8
> +#define COM1_DATACOM1_BASE+COM_OFFSET_DATA
> +#define COM1_IER COM1_BASE+COM_OFFSET_IER
> +#define COM1_IIR COM1_BASE+COM_OFFSET_IIR
> +#define COM1_LCR COM1_BASE+COM_OFFSET_LCR
> +#define COM1_MCR COM1_BASE+COM_OFFSET_MCR
> +#define COM1_LSR COM1_BASE+COM_OFFSET_LSR
> +#define COM1_MSR COM1_BASE+COM_OFFSET_MSR
> +#define COM1_SCR COM1_BASE+COM_OFFSET_SCR
> +
> +#define COM_OFFSET_DATA 0
> +#define COM_OFFSET_IER 1
> +#define COM_OFFSET_IIR 2
> +#define COM_OFFSET_LCR 3
> +#define COM_OFFSET_MCR 4
> +#define COM_OFFSET_LSR 5
> +#define COM_OFFSET_MSR 6
> +#define COM_OFFSET_SCR 7
> +
> +/* ns8250 port identifier */
> +enum ns8250_portid {
> + NS8250_COM1,
> + NS8250_COM2,
> +};
>
> /* ns8250 UART registers */
> struct ns8250_regs {
> @@ -50,6 +66,7 @@ struct ns8250_dev {
> struct event rate;
> struct event wake;
> struct timeval rate_tv;
> + enum ns8250_portid portid;
> int fd;
> int irq;
> int rcv_pending;
>
pf(4) man page: sync with net/pfvar.h
This syncs the pf(4) man page with the latest net/pfvar.h (r1.490).
ok?
Index: pf.4
===
RCS file: /cvs/src/share/man/man4/pf.4,v
retrieving revision 1.91
diff -u -p -r1.91 pf.4
--- pf.418 Feb 2019 13:11:44 - 1.91
+++ pf.423 May 2019 01:09:55 -
@@ -269,6 +269,7 @@ struct pf_status {
u_int64_t pcounters[2][2][3];
u_int64_t bcounters[2][2];
u_int64_t stateid;
+ u_int64_t syncookies_inflight[2]; /* unACKed SYNcookies */
time_t since;
u_int32_t running;
u_int32_t states;
@@ -277,6 +278,9 @@ struct pf_status {
u_int32_t debug;
u_int32_t hostid;
u_int32_t reass; /* reassembly */
+ u_int8_tsyncookies_active;
+ u_int8_tsyncookies_mode;/* never/always/adaptive */
+ u_int8_tpad[2];
charifname[IFNAMSIZ];
u_int8_tpf_chksum[PF_MD5_DIGEST_LENGTH];
};
@@ -411,7 +415,8 @@ struct pfioc_limit {
};
enum { PF_LIMIT_STATES, PF_LIMIT_SRC_NODES, PF_LIMIT_FRAGS,
- PF_LIMIT_TABLES, PF_LIMIT_TABLE_ENTRIES, PF_LIMIT_MAX };
+ PF_LIMIT_TABLES, PF_LIMIT_TABLE_ENTRIES, PF_LIMIT_PKTDELAY_PKTS,
+ PF_LIMIT_MAX };
.Ed
.It Dv DIOCGETLIMIT Fa "struct pfioc_limit *pl"
Get the hard
vmd(8): slight NS8250 fix
Hi,
Adjusted NS8250 behavior in vmd(8) so it gets detected as an 8250 and not a
16450 by OpenBSD’s boot process. Also generalized some of the COM1-specific I/O
address definitions to support adding COM2 (and COM3, and COM4…) in the future.
Tested by logging into my VM with the virtual serial console and reinstalling
6.5, everything was fine. The boot process detected an NS8250.
Index: ns8250.c
===
RCS file: /cvs/src/usr.sbin/vmd/ns8250.c,v
retrieving revision 1.20
diff -u -p -u -r1.20 ns8250.c
--- ns8250.c11 Mar 2019 17:08:52 - 1.20
+++ ns8250.c23 May 2019 00:52:15 -
@@ -74,6 +74,7 @@ ns8250_init(int fd, uint32_t vmid)
}
com1_dev.fd = fd;
com1_dev.irq = 4;
+ com1_dev.portid = NS8250_COM1;
com1_dev.rcv_pending = 0;
com1_dev.vmid = vmid;
com1_dev.byte_out = 0;
@@ -509,10 +510,10 @@ vcpu_process_com_scr(struct vm_exit *vei
/*
* vei_dir == VEI_DIR_OUT : out instruction
*
-* Write to SCR
+* The 8250 does not have a scratch register.
*/
if (vei->vei.vei_dir == VEI_DIR_OUT) {
- com1_dev.regs.scr = vei->vei.vei_data;
+ com1_dev.regs.scr = 0xFF;
} else {
/*
* vei_dir == VEI_DIR_IN : in instruction
@@ -647,6 +648,7 @@ ns8250_restore(int fd, int con_fd, uint3
}
com1_dev.fd = con_fd;
com1_dev.irq = 4;
+ com1_dev.portid = NS8250_COM1;
com1_dev.rcv_pending = 0;
com1_dev.vmid = vmid;
com1_dev.byte_out = 0;
Index: ns8250.h
===
RCS file: /cvs/src/usr.sbin/vmd/ns8250.h,v
retrieving revision 1.7
diff -u -p -u -r1.7 ns8250.h
--- ns8250.h11 Mar 2019 17:08:52 - 1.7
+++ ns8250.h23 May 2019 00:52:15 -
@@ -18,14 +18,30 @@
/*
* Emulated 8250 UART
*/
-#define COM1_DATA 0x3f8
-#define COM1_IER 0x3f9
-#define COM1_IIR 0x3fa
-#define COM1_LCR 0x3fb
-#define COM1_MCR 0x3fc
-#define COM1_LSR 0x3fd
-#define COM1_MSR 0x3fe
-#define COM1_SCR 0x3ff
+#define COM1_BASE 0x3f8
+#define COM1_DATA COM1_BASE+COM_OFFSET_DATA
+#define COM1_IER COM1_BASE+COM_OFFSET_IER
+#define COM1_IIR COM1_BASE+COM_OFFSET_IIR
+#define COM1_LCR COM1_BASE+COM_OFFSET_LCR
+#define COM1_MCR COM1_BASE+COM_OFFSET_MCR
+#define COM1_LSR COM1_BASE+COM_OFFSET_LSR
+#define COM1_MSR COM1_BASE+COM_OFFSET_MSR
+#define COM1_SCR COM1_BASE+COM_OFFSET_SCR
+
+#define COM_OFFSET_DATA 0
+#define COM_OFFSET_IER 1
+#define COM_OFFSET_IIR 2
+#define COM_OFFSET_LCR 3
+#define COM_OFFSET_MCR 4
+#define COM_OFFSET_LSR 5
+#define COM_OFFSET_MSR 6
+#define COM_OFFSET_SCR 7
+
+/* ns8250 port identifier */
+enum ns8250_portid {
+ NS8250_COM1,
+ NS8250_COM2,
+};
/* ns8250 UART registers */
struct ns8250_regs {
@@ -50,6 +66,7 @@ struct ns8250_dev {
struct event rate;
struct event wake;
struct timeval rate_tv;
+ enum ns8250_portid portid;
int fd;
int irq;
int rcv_pending;
Re: efiboot: allow bigger ucodes
> Date: Wed, 22 May 2019 20:02:14 +0200 > From: Alexander Bluhm > > On Wed, May 22, 2019 at 05:54:35PM +0200, Mark Kettenis wrote: > > Should we also fix biosboot? The machines that are affected are all > > fairly recent and should boot using UEFI by default... > > If we change fewer things, we may have less trouble for 6.4 and 6.5 > errata. > > Do we know any non-UEFI capable machines with huge firmware? The problem is that most UEFI capable machines still include a CSM module that provides classic BIOS support. While many modern machines disable this module by default, users can twidle knobs and may end up using biosboot. > Does boot on BIOS machines have enough memory to handle huge firmware? According to https://wiki.osdev.org/Memory_Map_(x86) the area from 0x0010-0x00EF should be free for use if it exists. Since we currently load our kernel at 0x0100 we already assume that memory exists. But there is no official standard so no absolute guarantee. My guess is that bumping the limit from 128k to 256k should work. Such a bump is fairly riskless since there is no impact on machines with "small" microcodes. > > I have no clue if/how this should be handled as an errata/syspatch. > > I think we should include this into errata. Otherwise x280 and > similar machines would not get new firmware. As claudio@ points out we provide mitigation against MDS even without the microcode. And vendors are much more likely to provide BIOS updates for machines with these fairly recent Intel CPUs than for 8-year old hardware, so I think there is a reasonable case for not bothering about 6.4 and 6.5 here. And... > First we need a diff for 6.5 and 6.5. exec_i386.c is based on > recent refactoring. > > Can we explain users to run installboot in errata description? > Do they know which boot disk to give on the command line? > > Can syspatch handle calling installboot? > Can it autodetect the boot disk device? ...given these complications I think we shouldn't bother and concentrating on getting the MDS errata/syspatch out that is currently being tested.
Re: pci_reserve_resources(9) fix
> Date: Tue, 21 May 2019 21:04:33 +0200 (CEST)
> From: Mark Kettenis
>
> Logic error. If pa->pa_pmemex is NULL we want to try allocating from
> pa->pa_memex. But if both of them are NULL we need to assume that the
> provided base address is correct.
>
> ok?
patrick@ pointed out an issue with this diff and I'm going to fix this
in a different way.
> Index: dev/pci/pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/pci.c,v
> retrieving revision 1.112
> diff -u -p -r1.112 pci.c
> --- dev/pci/pci.c 28 Jul 2018 15:28:51 - 1.112
> +++ dev/pci/pci.c 21 May 2019 19:00:01 -
> @@ -907,10 +907,10 @@ pci_reserve_resources(struct pci_attach_
> base = PCI_ROM_ADDR(addr);
> size = PCI_ROM_SIZE(mask);
> if (base != 0 && size != 0) {
> - if (pa->pa_pmemex && extent_alloc_region(pa->pa_pmemex,
> - base, size, EX_NOWAIT) &&
> - pa->pa_memex && extent_alloc_region(pa->pa_memex,
> - base, size, EX_NOWAIT)) {
> + if ((pa->pa_pmemex && extent_alloc_region(pa->pa_pmemex,
> + base, size, EX_NOWAIT)) ||
> + (pa->pa_memex && extent_alloc_region(pa->pa_memex,
> + base, size, EX_NOWAIT))) {
> printf("%d:%d:%d: mem address conflict
> 0x%lx/0x%lx\n",
> bus, dev, func, base, size);
> pci_conf_write(pc, tag, PCI_ROM_REG, 0);
>
>
Re: ssh-keygen: interactive comment change
On Wed, 22 May 2019, Mark Lumsden wrote:
Date: Wed, 22 May 2019 18:49:23 + (UTC)
From: Mark Lumsden
To: tech@openbsd.org
Subject: ssh-keygen: interactive comment change
I used the -C command line option of ssh-keygen to change the comment of a
public key and got confused with the output. For example, if the original
comment was 'mark@home', this is what would happen trying to amend the
comment to 'mark@work' via -C:
$ ssh-keygen -f test_rsa -c -C mark@work
Key now has comment 'mark@home'
The comment in your key file has been changed.
$
The line "Key now has comment 'mark@home'" suggested to me that the comment
had been changed to 'mark@home'. But thats not really a change. However, the
comment had actually changed in the .pub file. It looks like the wording has
been designed to work without the -C option and _only_ the -c option:
$ ssh-keygen -f test_rsa -c
Key now has comment 'mark@home'
Enter new comment: mark@work
The comment in your key file has been changed.
$
Everything becomes clear when you run the command interactively via -c only.
The diff below attempts to make the wording make sense which ever way you try
to change a comment on a .pub file:
$ ssh-keygen -f test_rsa -c
Old comment: mark@home
New comment: mark@work
Comment 'mark@work' applied
$
$ ssh-keygen -f test_rsa -c -C mark@work
Old comment: mark@home
Comment 'mark@work' applied
$
It also compares the old and new comments and informs if there is no change:
$ ssh-keygen -f test_rsa -c -C mark@home
Old comment: mark@home
No change to comment
$
$ ssh-keygen -f test_rsa -c
Old comment: mark@work
New comment: mark@work
No change to comment
$
ok?
Mark
Here is a better diff.
It doesn't say that the public key has been written, until it has
actually been written.
If there is no change detected in the old and new comments, it doesn't try
and write anything, just cleans up and exits.
Index: ssh-keygen.c
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v
retrieving revision 1.329
diff -u -p -u -p -r1.329 ssh-keygen.c
--- ssh-keygen.c25 Mar 2019 16:19:44 - 1.329
+++ ssh-keygen.c22 May 2019 19:40:49 -
@@ -1466,15 +1466,15 @@ do_change_comment(struct passwd *pw, con
sshkey_free(private);
exit(1);
}
- if (comment)
- printf("Key now has comment '%s'\n", comment);
+ if (strlen(comment) > 0)
+ printf("Old comment: %s\n", comment);
else
- printf("Key now has no comment\n");
+ printf("No existing comment\n");
if (identity_comment) {
strlcpy(new_comment, identity_comment, sizeof(new_comment));
} else {
- printf("Enter new comment: ");
+ printf("New comment: ");
fflush(stdout);
if (!fgets(new_comment, sizeof(new_comment), stdin)) {
explicit_bzero(passphrase, strlen(passphrase));
@@ -1483,6 +1483,13 @@ do_change_comment(struct passwd *pw, con
}
new_comment[strcspn(new_comment, "\n")] = '\0';
}
+ if (strcmp(comment, new_comment) == 0) {
+ printf("No change to comment\n");
+ free(passphrase);
+ sshkey_free(private);
+ free(comment);
+ exit(0);
+ }
/* Save the file using the new passphrase. */
if ((r = sshkey_save_private(private, identity_file, passphrase,
@@ -1514,9 +1521,13 @@ do_change_comment(struct passwd *pw, con
fprintf(f, " %s\n", new_comment);
fclose(f);
+ if (strlen(new_comment) > 0)
+ printf("Comment '%s' applied\n", new_comment);
+ else
+ printf("Comment removed\n");
+
free(comment);
- printf("The comment in your key file has been changed.\n");
exit(0);
}
ssh-keygen: interactive comment change
I used the -C command line option of ssh-keygen to change the comment
of a public key and got confused with the output. For example, if the
original comment was 'mark@home', this is what would happen trying to
amend the comment to 'mark@work' via -C:
$ ssh-keygen -f test_rsa -c -C mark@work
Key now has comment 'mark@home'
The comment in your key file has been changed.
$
The line "Key now has comment 'mark@home'" suggested to me that the
comment had been changed to 'mark@home'. But thats not really a change.
However, the comment had actually changed in the .pub file. It looks like
the wording has been designed to work without the -C option and _only_ the
-c option:
$ ssh-keygen -f test_rsa -c
Key now has comment 'mark@home'
Enter new comment: mark@work
The comment in your key file has been changed.
$
Everything becomes clear when you run the command interactively via -c
only.
The diff below attempts to make the wording make sense which ever way you
try to change a comment on a .pub file:
$ ssh-keygen -f test_rsa -c
Old comment: mark@home
New comment: mark@work
Comment 'mark@work' applied
$
$ ssh-keygen -f test_rsa -c -C mark@work
Old comment: mark@home
Comment 'mark@work' applied
$
It also compares the old and new comments and informs if there is no
change:
$ ssh-keygen -f test_rsa -c -C mark@home
Old comment: mark@home
No change to comment
$
$ ssh-keygen -f test_rsa -c
Old comment: mark@work
New comment: mark@work
No change to comment
$
ok?
Mark
Index: ssh-keygen.c
===
RCS file: /cvs/src/usr.bin/ssh/ssh-keygen.c,v
retrieving revision 1.329
diff -u -p -u -p -r1.329 ssh-keygen.c
--- ssh-keygen.c25 Mar 2019 16:19:44 - 1.329
+++ ssh-keygen.c22 May 2019 18:21:42 -
@@ -1466,15 +1466,15 @@ do_change_comment(struct passwd *pw, con
sshkey_free(private);
exit(1);
}
- if (comment)
- printf("Key now has comment '%s'\n", comment);
+ if (strlen(comment) > 0)
+ printf("Old comment: %s\n", comment);
else
- printf("Key now has no comment\n");
+ printf("No existing comment\n");
if (identity_comment) {
strlcpy(new_comment, identity_comment, sizeof(new_comment));
} else {
- printf("Enter new comment: ");
+ printf("New comment: ");
fflush(stdout);
if (!fgets(new_comment, sizeof(new_comment), stdin)) {
explicit_bzero(passphrase, strlen(passphrase));
@@ -1483,6 +1483,12 @@ do_change_comment(struct passwd *pw, con
}
new_comment[strcspn(new_comment, "\n")] = '\0';
}
+ if (strcmp(comment, new_comment) == 0)
+ printf("No change to comment\n");
+ else if (strlen(new_comment) > 0)
+ printf("Comment '%s' applied\n", new_comment);
+ else
+ printf("Comment removed\n");
/* Save the file using the new passphrase. */
if ((r = sshkey_save_private(private, identity_file, passphrase,
@@ -1516,7 +1522,6 @@ do_change_comment(struct passwd *pw, con
free(comment);
- printf("The comment in your key file has been changed.\n");
exit(0);
}
Re: efiboot: allow bigger ucodes
On Wed, May 22, 2019 at 08:02:14PM +0200, Alexander Bluhm wrote: > On Wed, May 22, 2019 at 05:54:35PM +0200, Mark Kettenis wrote: > > Should we also fix biosboot? The machines that are affected are all > > fairly recent and should boot using UEFI by default... > > If we change fewer things, we may have less trouble for 6.4 and 6.5 > errata. > > Do we know any non-UEFI capable machines with huge firmware? > Does boot on BIOS machines have enough memory to handle huge firmware? > > > I have no clue if/how this should be handled as an errata/syspatch. > > I think we should include this into errata. Otherwise x280 and > similar machines would not get new firmware. > > First we need a diff for 6.5 and 6.5. exec_i386.c is based on > recent refactoring. > > Can we explain users to run installboot in errata description? > Do they know which boot disk to give on the command line? > > Can syspatch handle calling installboot? > Can it autodetect the boot disk device? Do we really need to do that? I think all these laptops should have updates for the BIOS. I think it would be the better option to tell people to update the BIOS instead of doing a bootloader update in syspatch. In the end if the update is not installed then the fall back code will be used which is maybe not optimal but should also work. -- :wq Claudio
Re: efiboot: allow bigger ucodes
On Wed, May 22, 2019 at 05:54:35PM +0200, Mark Kettenis wrote: > Should we also fix biosboot? The machines that are affected are all > fairly recent and should boot using UEFI by default... If we change fewer things, we may have less trouble for 6.4 and 6.5 errata. Do we know any non-UEFI capable machines with huge firmware? Does boot on BIOS machines have enough memory to handle huge firmware? > I have no clue if/how this should be handled as an errata/syspatch. I think we should include this into errata. Otherwise x280 and similar machines would not get new firmware. First we need a diff for 6.5 and 6.5. exec_i386.c is based on recent refactoring. Can we explain users to run installboot in errata description? Do they know which boot disk to give on the command line? Can syspatch handle calling installboot? Can it autodetect the boot disk device? bluhm
Re: efiboot: allow bigger ucodes
> Date: Wed, 22 May 2019 00:40:24 -0700
> From: Mike Larkin
>
> On Tue, May 21, 2019 at 12:33:24AM +0200, Mark Kettenis wrote:
> > > Date: Sat, 18 May 2019 05:58:39 +0200 (CEST)
> > > From: Mark Kettenis
> > >
> > > > Date: Fri, 17 May 2019 17:56:52 -0400
> > > > From: Patrick Wildt
> > > >
> > > > Hi,
> > > >
> > > > claudio@ has a Kaby Lake that exceeds the 128 kB limit, being as big as
> > > > 190 kB. So, for him the ucode isn't being loaded.
> > > >
> > > > On EFI systems we can simply ask EFI to allocate some memory for us.
> > > > I'm not sure why this file is duplicated 4 times, but it looks like
> > > > for efiboot this one is currently the file to patch.
> > > >
> > > > This diff works for claudio@'s EFI booted system. Since I don't know
> > > > how much space is available on legacy systems I will not attempt to
> > > > fix this for the legacy bootloader. Someone that knows more than me
> > > > about x86 can attempt that.
> > > >
> > > > Feedback? ok?
> > >
> > > In principle, ye, that is the right approach.
> > >
> > > However, until Mike gets us to the point where we no longer care at
> > > which physical address the kernel was loaded, efiboot will move the
> > > kernel to a specific physical address after loading it and potentially
> > > thrash all memory allocated through the EFI interfaces. So there is a
> > > change that we will overwrite the microcode at that point.
> > >
> > > So it might actually be safer to just change the limit to 256k if
> > > there is a good chance the the memory at the 1MB mark is unlikely to
> > > be used by anything else.
> >
> > Actually, since we always move the kernel to 16MB, we can use
> > AllocateMaxAddress to allocate a large enough block of memory below
> > that. So the diff below should work (and does on my Skylake system
> > that uses a 100k firmware).
> >
> > ok?
> >
>
> While I am frightened about gigantisch microcodes and EFI trying to
> fit things into lowmem below the ISA hole, I suppose it knows what
> it's doing.
If EFI needs the lowmem, it won't give it to us. When the EFI memory
map gets converted to an old-style BIOS memory map, this block of
memory will be marked free, so the lowmem gobbled up here will remain
available to our kernel. The kernel copies the ucode to a safe place
early on. I'm not convinced that happens early enough though, but
that's not a new problem...
> ok mlarkin, not sure how you want to integrate this into the MDS
> stuff that is being worked on though. I'll take care of merging this
> into efi32/efi64 when I'm ready.
Should we also fix biosboot? The machines that are affected are all
fairly recent and should boot using UEFI by default...
I have no clue if/how this should be handled as an errata/syspatch.
> > Index: arch/amd64/stand/efiboot/exec_i386.c
> > ===
> > RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/exec_i386.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 exec_i386.c
> > --- arch/amd64/stand/efiboot/exec_i386.c10 May 2019 21:20:42 -
> > 1.1
> > +++ arch/amd64/stand/efiboot/exec_i386.c20 May 2019 22:25:38 -
> > @@ -46,8 +46,13 @@
> > #include "softraid_amd64.h"
> > #endif
> >
> > +#include
> > +#include
> > +#include "eficall.h"
> > #include "efiboot.h"
> >
> > +extern EFI_BOOT_SERVICES *BS;
> > +
> > typedef void (*startfuncp)(int, int, int, int, int, int, int, int)
> > __attribute__ ((noreturn));
> >
> > @@ -165,6 +170,7 @@ run_loadfile(uint64_t *marks, int howto)
> > void
> > ucode_load(void)
> > {
> > + EFI_PHYSICAL_ADDRESS addr;
> > uint32_t model, family, stepping;
> > uint32_t dummy, signature;
> > uint32_t vendor[4];
> > @@ -200,12 +206,13 @@ ucode_load(void)
> > return;
> >
> > buflen = sb.st_size;
> > - if (buflen > 128*1024) {
> > - printf("ucode too large\n");
> > + addr = 16 * 1024 * 1024;
> > + if (EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData,
> > + EFI_SIZE_TO_PAGES(buflen), ) != EFI_SUCCESS) {
> > + printf("cannot allocate memory for ucode\n");
> > return;
> > }
> > -
> > - buf = (char *)(1*1024*1024);
> > + buf = (char *)((paddr_t)addr);
> >
> > if (read(fd, buf, buflen) != buflen) {
> > close(fd);
> >
> >
>
Re: rtcdrain: fix function reference in comment
On 21/05/19(Tue) 20:41, Jasper Lievisse Adriaanse wrote: > Hi, > > This appears to have been wrong from the import, the comment explaining why > rtcdrain() is needed is in rtcstart() in the same file. OK? I'd rather kill the reference. It will become outdated next time somebody refactor the code. Plus it creates grep(1) noise (: > Index: amd64/isa/clock.c > === > RCS file: /cvs/src/sys/arch/amd64/isa/clock.c,v > retrieving revision 1.28 > diff -u -p -r1.28 clock.c > --- amd64/isa/clock.c 27 Jul 2018 21:11:31 - 1.28 > +++ amd64/isa/clock.c 21 May 2019 18:36:13 - > @@ -291,7 +291,7 @@ rtcdrain(void *v) > > /* > * Drain any un-acknowledged RTC interrupts. > - * See comment in cpu_initclocks(). > + * See comment in rtcstart(). > */ > while (mc146818_read(NULL, MC_REGC) & MC_REGC_PF) > ; /* Nothing. */ > Index: i386/isa/clock.c > === > RCS file: /cvs/src/sys/arch/i386/isa/clock.c,v > retrieving revision 1.53 > diff -u -p -r1.53 clock.c > --- i386/isa/clock.c 30 Jul 2018 14:19:12 - 1.53 > +++ i386/isa/clock.c 21 May 2019 18:36:13 - > @@ -192,7 +192,7 @@ rtcdrain(void *v) > > /* >* Drain any un-acknowledged RTC interrupts. > - * See comment in cpu_initclocks(). > + * See comment in rtcstart(). >*/ > while (mc146818_read(NULL, MC_REGC) & MC_REGC_PF) > ; /* Nothing. */ > -- > jasper >
Re: [PATCH] mg: {beginning,end}-of-buffer don't set marks in Emacs
Regardless of the decision on which way the behavior should go, it is a documentation bug either way. (E.g. beginning-of-buffer is missed entirely). Probably my fault (from a lng time ago.) On Wed, May 22, 2019 at 8:53 AM Leonid Bobrov wrote: > On Wed, May 22, 2019 at 01:36:41PM +0200, Jeremie Courreges-Anglas wrote: > > On Wed, May 22 2019, Leonid Bobrov wrote: > > > It seems that nobody cares about compatibility with GNU Emacs. Besides > > > this behaviour is annoying because when I set a mark, scroll a buffer, > > > and decide to go to the end of buffer that overwrites my mark and I > have > > > to start over. Also besides that you have to figure out this behavior > > > because manpage just says: > > > ``` > > >M-< beginning-of-buffer > > >M-> end-of-buffer > > > ``` > > > Should we consider this documentation bug and patch a manpage? > > > > > > On Thu, Feb 14, 2019 at 04:46:21PM +0200, Leonid Bobrov wrote: > > >> Ping. > > >> > > >> On Wed, Feb 06, 2019 at 11:29:47PM +0200, Leonid Bobrov wrote: > > >> > Hi! > > >> > > > >> > Going to end and begging of buffer doesn't set marks in Emacs. > > > > This doesn't match my understanding of marks in emacs, nor what emacs > > C-h k says: > > > > --8<-- > > M-< runs the command beginning-of-buffer (found in global-map), which is > > an interactive compiled Lisp function in ‘simple.el’. > > > > It is bound to ., b, , , , > > M-<,. > > > > (beginning-of-buffer ARG) > > > > This function is for interactive use only; > > in Lisp code use `(goto-char (point-min))' instead. > > > > Move point to the beginning of the buffer. > > With numeric arg N, put point N/10 of the way from the beginning. > > If the buffer is narrowed, this command uses the beginning of the > > accessible part of the buffer. > > > > Push mark at previous position, unless either a C-u prefix > > ^^ > > is supplied, or Transient Mark mode is enabled and the mark is active. > > -->8-- > > > > So if you're pushing for a change here we'd need a better explanation. > > > > -- > > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 > E7EE > > > > Oh, I haven't noticed that behavior in Emacs before. So, if I haven't > pushed a mark before, then Emacs will automatically push it (while mg > pushes it in all cases). > > Also that C-u prefix part is not true (I made a check, also thank you > for new knowledge), in Emacs it pushes a mark if I haven't pushed it > myself. > > In Emacs Transient Mark mode is on by default, but mg doesn't have this > mode. Also mg doesn't have that N/10 behavior when giving it a numeric > arg. > > In order to be compatible with GNU Emacs, I have to implement Transient > Mark mode, make it on by default, while in this mode using M-< and M-> > shouldn't push mark if it's active and I have to implement N/10 behavior > when giving a numeric arg to M-< and M->, is everything correct? > >
pledge(2) unbound-checkconf(8)
Hi,
unbound-checkconf(8) needs to chdir(2) and then open(2) the config file and
to call getpwnam(3). This means it needs to pledge for rpath and getpw, but
after calling getpwnam(3) the config file was already loaded so we can drop
both promises afterwards.
Comments? OK?
Index: unbound-checkconf.c
===
RCS file: /cvs/src/usr.sbin/unbound/smallapp/unbound-checkconf.c,v
retrieving revision 1.11
diff -u -p -u -r1.11 unbound-checkconf.c
--- unbound-checkconf.c 8 Feb 2019 10:29:08 - 1.11
+++ unbound-checkconf.c 22 May 2019 12:49:12 -
@@ -588,6 +588,10 @@ morechecks(struct config_file* cfg)
# endif
}
#endif
+
+ if (pledge("stdio", NULL) == -1)
+ fatal_exit("Could not pledge");
+
if(cfg->remote_control_enable && options_remote_is_address(cfg)
&& cfg->control_use_cert) {
check_chroot_string("server-key-file", >server_key_file,
@@ -724,6 +728,10 @@ int main(int argc, char* argv[])
if(argc == 1)
f = argv[0];
elsef = cfgfile;
+
+ if (pledge("stdio rpath getpw", NULL) == -1)
+ fatal_exit("Could not pledge");
+
checkconf(f, opt, final);
checklock_stop();
return 0;
Re: [PATCH] mg: {beginning,end}-of-buffer don't set marks in Emacs
On Wed, May 22, 2019 at 01:36:41PM +0200, Jeremie Courreges-Anglas wrote: > On Wed, May 22 2019, Leonid Bobrov wrote: > > It seems that nobody cares about compatibility with GNU Emacs. Besides > > this behaviour is annoying because when I set a mark, scroll a buffer, > > and decide to go to the end of buffer that overwrites my mark and I have > > to start over. Also besides that you have to figure out this behavior > > because manpage just says: > > ``` > >M-< beginning-of-buffer > >M-> end-of-buffer > > ``` > > Should we consider this documentation bug and patch a manpage? > > > > On Thu, Feb 14, 2019 at 04:46:21PM +0200, Leonid Bobrov wrote: > >> Ping. > >> > >> On Wed, Feb 06, 2019 at 11:29:47PM +0200, Leonid Bobrov wrote: > >> > Hi! > >> > > >> > Going to end and begging of buffer doesn't set marks in Emacs. > > This doesn't match my understanding of marks in emacs, nor what emacs > C-h k says: > > --8<-- > M-< runs the command beginning-of-buffer (found in global-map), which is > an interactive compiled Lisp function in ‘simple.el’. > > It is bound to ., b, , , , > M-<,. > > (beginning-of-buffer ARG) > > This function is for interactive use only; > in Lisp code use `(goto-char (point-min))' instead. > > Move point to the beginning of the buffer. > With numeric arg N, put point N/10 of the way from the beginning. > If the buffer is narrowed, this command uses the beginning of the > accessible part of the buffer. > > Push mark at previous position, unless either a C-u prefix > ^^ > is supplied, or Transient Mark mode is enabled and the mark is active. > -->8-- > > So if you're pushing for a change here we'd need a better explanation. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > Oh, I haven't noticed that behavior in Emacs before. So, if I haven't pushed a mark before, then Emacs will automatically push it (while mg pushes it in all cases). Also that C-u prefix part is not true (I made a check, also thank you for new knowledge), in Emacs it pushes a mark if I haven't pushed it myself. In Emacs Transient Mark mode is on by default, but mg doesn't have this mode. Also mg doesn't have that N/10 behavior when giving it a numeric arg. In order to be compatible with GNU Emacs, I have to implement Transient Mark mode, make it on by default, while in this mode using M-< and M-> shouldn't push mark if it's active and I have to implement N/10 behavior when giving a numeric arg to M-< and M->, is everything correct?
Re: net80211: fix ifconfig mode command
On Mon, Apr 15, 2019 at 04:56:52PM +0200, Stefan Sperling wrote:
> The ifconfig mode command is broken; It is supposed to force a wireless
> interface into 11a/b/g/n media mode. This stopped working some time ago,
> probably during my work on background scanning. Problem spotted by mlarkin@
> who noticed that interfaces were using 11g mode while forced to 11b mode.
>
> The diff below allows me to force media modes again on iwm(4), urtwn(4),
> and athn(4), with e.g. 'ifconfig iwm0 mode 11b' More tests welcome.
>
> Note that the stack will autoselect a mode by default and things will
> usually just work. So this isn't a critical issue unless a mode needs to
> be forced for some reason. The main purpose of switching modes is to
> restrict drivers to a particular set of channels and Tx rates.
The previous version of this diff had a bug which would cause recursion
in ieee80211_end_scan() followed by a panic in ieee80211_fix_rate().
Here is a new diff with that problem fixed; ok?
diff e7d7f4196e8f84e5d8b61c3e357f85fa9b4a44db /usr/src
blob - d362284ff0b163b77ec8774f5307d6becbc867c0
file + sys/net80211/ieee80211.c
--- sys/net80211/ieee80211.c
+++ sys/net80211/ieee80211.c
@@ -1007,6 +1007,7 @@ enum ieee80211_phymode
ieee80211_next_mode(struct ifnet *ifp)
{
struct ieee80211com *ic = (void *)ifp;
+ uint16_t mode;
if (IFM_MODE(ic->ic_media.ifm_cur->ifm_media) != IFM_AUTO) {
/*
@@ -1018,36 +1019,52 @@ ieee80211_next_mode(struct ifnet *ifp)
}
/*
-* Get the next supported mode
+* Always scan in AUTO mode if the driver scans all bands, and
+* leave the current mode as it is.
*/
- for (++ic->ic_curmode;
- ic->ic_curmode <= IEEE80211_MODE_MAX;
- ic->ic_curmode++) {
+ if (ic->ic_caps & IEEE80211_C_SCANALLBAND)
+ return (IEEE80211_MODE_AUTO);
+
+ /*
+* Get the next supported mode; effectively, this alternates between
+* the 11a (5GHz) and 11b/g (2GHz) modes. What matters is that each
+* supported channel gets scanned.
+*/
+ for (mode = ic->ic_curmode + 1; mode <= IEEE80211_MODE_MAX; mode++) {
/*
* Skip over 11n mode. Its set of channels is the superset
* of all channels supported by the other modes.
*/
- if (ic->ic_curmode == IEEE80211_MODE_11N)
+ if (mode == IEEE80211_MODE_11N)
continue;
/*
* Skip over 11ac mode. Its set of channels is the set
* of all channels supported by 11a.
*/
- if (ic->ic_curmode == IEEE80211_MODE_11AC)
+ if (mode == IEEE80211_MODE_11AC)
continue;
- /* Always scan in AUTO mode if the driver scans all bands. */
- if (ic->ic_curmode >= IEEE80211_MODE_MAX ||
- (ic->ic_caps & IEEE80211_C_SCANALLBAND)) {
- ic->ic_curmode = IEEE80211_MODE_AUTO;
+ if (ic->ic_modecaps & (1 << IEEE80211_MODE_11G)) {
+ /*
+* Skip over 11b mode. Its set of channels is
+* the set of all channels supported by 11g.
+*/
+ if (mode == IEEE80211_MODE_11B)
+ continue;
+ }
+
+ /* Start over if we have already tried all modes. */
+ if (mode == IEEE80211_MODE_MAX) {
+ mode = IEEE80211_MODE_AUTO;
break;
}
- if (ic->ic_modecaps & (1 << ic->ic_curmode))
+ if (ic->ic_modecaps & (1 << mode))
break;
}
- ieee80211_setmode(ic, ic->ic_curmode);
+ if (mode != ic->ic_curmode)
+ ieee80211_setmode(ic, mode);
return (ic->ic_curmode);
}
@@ -1058,26 +1075,41 @@ ieee80211_next_mode(struct ifnet *ifp)
* work here assumes how things work elsewhere in this code.
*
* Because the result of this function is ultimately used to select a
- * rate from the rate set of the returned mode, it must not return
- * IEEE80211_MODE_11N, which uses MCS instead of rates for unicast frames.
+ * rate from the rate set of the returned mode, it must return one of the
+ * legacy 11a/b/g modes; 11n and 11ac modes use MCS instead of rate sets.
*/
enum ieee80211_phymode
ieee80211_chan2mode(struct ieee80211com *ic,
const struct ieee80211_channel *chan)
{
/*
+* Are we fixed in 11a/b/g mode?
* NB: this assumes the channel would not be supplied to us
* unless it was already compatible with the current mode.
*/
- if (ic->ic_curmode != IEEE80211_MODE_11N &&
- ic->ic_curmode != IEEE80211_MODE_11AC &&
- (ic->ic_curmode != IEEE80211_MODE_AUTO ||
-
Re: [PATCH] mg: {beginning,end}-of-buffer don't set marks in Emacs
On Wed, May 22 2019, Leonid Bobrov wrote: > It seems that nobody cares about compatibility with GNU Emacs. Besides > this behaviour is annoying because when I set a mark, scroll a buffer, > and decide to go to the end of buffer that overwrites my mark and I have > to start over. Also besides that you have to figure out this behavior > because manpage just says: > ``` >M-< beginning-of-buffer >M-> end-of-buffer > ``` > Should we consider this documentation bug and patch a manpage? > > On Thu, Feb 14, 2019 at 04:46:21PM +0200, Leonid Bobrov wrote: >> Ping. >> >> On Wed, Feb 06, 2019 at 11:29:47PM +0200, Leonid Bobrov wrote: >> > Hi! >> > >> > Going to end and begging of buffer doesn't set marks in Emacs. This doesn't match my understanding of marks in emacs, nor what emacs C-h k says: --8<-- M-< runs the command beginning-of-buffer (found in global-map), which is an interactive compiled Lisp function in ‘simple.el’. It is bound to ., b, , , , M-<,. (beginning-of-buffer ARG) This function is for interactive use only; in Lisp code use `(goto-char (point-min))' instead. Move point to the beginning of the buffer. With numeric arg N, put point N/10 of the way from the beginning. If the buffer is narrowed, this command uses the beginning of the accessible part of the buffer. Push mark at previous position, unless either a C-u prefix ^^ is supplied, or Transient Mark mode is enabled and the mark is active. -->8-- So if you're pushing for a change here we'd need a better explanation. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
ldpd(8): unveil(2) main proc / reduce pledge(2) on ldpe
Hi,
Like we did on other daemons that cannot be pledged due to forbidden ioctls the
main process can be unveiled to restrict filesystem access. In this case we can
restrict it to only read, although it must be the entire / since the daemon is
able to include config files from anywhere.
Additionally the ldpe process currently has cpath promise to unlink the socket,
nevertheless the socket is actually unlinked from the main proc so this
permission can be removed. As we discussed before leaving the socket behind
doesn't do any harm that's why I didn't unveil it in the main proc.
Comments? OK?
Index: ldpd.c
===
RCS file: /cvs/src/usr.sbin/ldpd/ldpd.c,v
retrieving revision 1.64
diff -u -p -u -r1.64 ldpd.c
--- ldpd.c 31 Mar 2019 03:36:18 - 1.64
+++ ldpd.c 22 May 2019 11:09:33 -
@@ -222,6 +222,11 @@ main(int argc, char *argv[])
pipe_parent2ldpe[1], debug, global.cmd_opts & LDPD_OPT_VERBOSE,
sockname);
+ if (unveil("/", "r") == -1)
+ fatal("unveil");
+ if (unveil(NULL, NULL) == -1)
+ fatal("unveil");
+
event_init();
/* setup signal handler */
Index: ldpe.c
===
RCS file: /cvs/src/usr.sbin/ldpd/ldpe.c,v
retrieving revision 1.75
diff -u -p -u -r1.75 ldpe.c
--- ldpe.c 23 Jan 2019 02:02:04 - 1.75
+++ ldpe.c 22 May 2019 11:09:33 -
@@ -107,7 +107,7 @@ ldpe(int debug, int verbose, char *sockn
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
- if (pledge("stdio cpath inet mcast recvfd", NULL) == -1)
+ if (pledge("stdio inet mcast recvfd", NULL) == -1)
fatal("pledge");
event_init();
[patch] use acme-client to sign certificated with ecdsa keys
Hello,
First, sorry for double posting to misc@.
This is a short patch to let acme-client accept ECDSA keys now that
letsencrypt accepts signing certificates with those keys. This
functionality is present in certbot, so it might be a good idea to let
acme-client accept that too.
The key needs to be generated manually
i.e.: openssl ecparam -genkey -name secp384r1 -out privkey.pem
Best Regards
Index: rsa.c
===
RCS file: /cvs/src/usr.sbin/acme-client/rsa.c,v
retrieving revision 1.7
diff -u -p -r1.7 rsa.c
--- rsa.c 28 Jul 2018 15:25:23 - 1.7
+++ rsa.c 22 May 2019 11:17:47 -
@@ -79,7 +79,8 @@ rsa_key_load(FILE *f, const char *fname)
if (pkey == NULL) {
warnx("%s: PEM_read_PrivateKey", fname);
return NULL;
- } else if (EVP_PKEY_type(pkey->type) == EVP_PKEY_RSA)
+ } else if (EVP_PKEY_type(pkey->type) == EVP_PKEY_RSA ||
+ EVP_PKEY_type(pkey->type) == EVP_PKEY_EC )
return pkey;
warnx("%s: unsupported key type", fname);
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH] mg: {beginning,end}-of-buffer don't set marks in Emacs
It seems that nobody cares about compatibility with GNU Emacs. Besides
this behaviour is annoying because when I set a mark, scroll a buffer,
and decide to go to the end of buffer that overwrites my mark and I have
to start over. Also besides that you have to figure out this behavior
because manpage just says:
```
M-< beginning-of-buffer
M-> end-of-buffer
```
Should we consider this documentation bug and patch a manpage?
On Thu, Feb 14, 2019 at 04:46:21PM +0200, Leonid Bobrov wrote:
> Ping.
>
> On Wed, Feb 06, 2019 at 11:29:47PM +0200, Leonid Bobrov wrote:
> > Hi!
> >
> > Going to end and begging of buffer doesn't set marks in Emacs.
> >
> > Index: basic.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/basic.c,v
> > retrieving revision 1.47
> > diff -u -p -u -p -r1.47 basic.c
> > --- basic.c 10 Oct 2015 09:13:14 - 1.47
> > +++ basic.c 6 Feb 2019 21:18:34 -
> > @@ -122,7 +122,6 @@ forwchar(int f, int n)
> > int
> > gotobob(int f, int n)
> > {
> > - (void) setmark(f, n);
> > curwp->w_dotp = bfirstlp(curbp);
> > curwp->w_doto = 0;
> > curwp->w_rflag |= WFFULL;
> > @@ -140,7 +139,6 @@ gotoeob(int f, int n)
> > {
> > struct line *lp;
> >
> > - (void) setmark(f, n);
> > curwp->w_dotp = blastlp(curbp);
> > curwp->w_doto = llength(curwp->w_dotp);
> > curwp->w_dotline = curwp->w_bufp->b_lines;
> > Index: region.c
> > ===
> > RCS file: /cvs/src/usr.bin/mg/region.c,v
> > retrieving revision 1.37
> > diff -u -p -u -p -r1.37 region.c
> > --- region.c9 Sep 2016 06:05:51 - 1.37
> > +++ region.c6 Feb 2019 21:18:34 -
> > @@ -405,6 +405,7 @@ markbuffer(int f, int n)
> > {
> > if (gotoeob(f,n) == FALSE)
> > return (FALSE);
> > + (void) setmark(f, n);
> > if (gotobob(f,n) == FALSE)
> > return (FALSE);
> > return (TRUE);
> >
>
Re: efiboot: allow bigger ucodes
On Tue, May 21, 2019 at 12:33:24AM +0200, Mark Kettenis wrote:
> > Date: Sat, 18 May 2019 05:58:39 +0200 (CEST)
> > From: Mark Kettenis
> >
> > > Date: Fri, 17 May 2019 17:56:52 -0400
> > > From: Patrick Wildt
> > >
> > > Hi,
> > >
> > > claudio@ has a Kaby Lake that exceeds the 128 kB limit, being as big as
> > > 190 kB. So, for him the ucode isn't being loaded.
> > >
> > > On EFI systems we can simply ask EFI to allocate some memory for us.
> > > I'm not sure why this file is duplicated 4 times, but it looks like
> > > for efiboot this one is currently the file to patch.
> > >
> > > This diff works for claudio@'s EFI booted system. Since I don't know
> > > how much space is available on legacy systems I will not attempt to
> > > fix this for the legacy bootloader. Someone that knows more than me
> > > about x86 can attempt that.
> > >
> > > Feedback? ok?
> >
> > In principle, ye, that is the right approach.
> >
> > However, until Mike gets us to the point where we no longer care at
> > which physical address the kernel was loaded, efiboot will move the
> > kernel to a specific physical address after loading it and potentially
> > thrash all memory allocated through the EFI interfaces. So there is a
> > change that we will overwrite the microcode at that point.
> >
> > So it might actually be safer to just change the limit to 256k if
> > there is a good chance the the memory at the 1MB mark is unlikely to
> > be used by anything else.
>
> Actually, since we always move the kernel to 16MB, we can use
> AllocateMaxAddress to allocate a large enough block of memory below
> that. So the diff below should work (and does on my Skylake system
> that uses a 100k firmware).
>
> ok?
>
While I am frightened about gigantisch microcodes and EFI trying to fit things
into lowmem below the ISA hole, I suppose it knows what it's doing.
ok mlarkin, not sure how you want to integrate this into the MDS stuff
that is being worked on though. I'll take care of merging this into efi32/efi64
when I'm ready.
>
> Index: arch/amd64/stand/efiboot/exec_i386.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/efiboot/exec_i386.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 exec_i386.c
> --- arch/amd64/stand/efiboot/exec_i386.c 10 May 2019 21:20:42 -
> 1.1
> +++ arch/amd64/stand/efiboot/exec_i386.c 20 May 2019 22:25:38 -
> @@ -46,8 +46,13 @@
> #include "softraid_amd64.h"
> #endif
>
> +#include
> +#include
> +#include "eficall.h"
> #include "efiboot.h"
>
> +extern EFI_BOOT_SERVICES *BS;
> +
> typedef void (*startfuncp)(int, int, int, int, int, int, int, int)
> __attribute__ ((noreturn));
>
> @@ -165,6 +170,7 @@ run_loadfile(uint64_t *marks, int howto)
> void
> ucode_load(void)
> {
> + EFI_PHYSICAL_ADDRESS addr;
> uint32_t model, family, stepping;
> uint32_t dummy, signature;
> uint32_t vendor[4];
> @@ -200,12 +206,13 @@ ucode_load(void)
> return;
>
> buflen = sb.st_size;
> - if (buflen > 128*1024) {
> - printf("ucode too large\n");
> + addr = 16 * 1024 * 1024;
> + if (EFI_CALL(BS->AllocatePages, AllocateMaxAddress, EfiLoaderData,
> + EFI_SIZE_TO_PAGES(buflen), ) != EFI_SUCCESS) {
> + printf("cannot allocate memory for ucode\n");
> return;
> }
> -
> - buf = (char *)(1*1024*1024);
> + buf = (char *)((paddr_t)addr);
>
> if (read(fd, buf, buflen) != buflen) {
> close(fd);
>
>
