Without this change a local attacker could trigger a panic by
tricking the kernel into accessing undefined kernel memory.
We would like to acknowledge Francisco Falcon from CORE Security
Technologies who discovered the issue and reported to the
FreeBSD Security Team.
More information can be found at CORE Security's advisory at:
http://www.coresecurity.com/content/freebsd-kernel-multiple-vulnerabilities
This is an errata candidate for releng/10.1 and releng/9.3. Earlier
releases are not affected.
Reported by: Francisco Falcon from CORE Security Technologies
Security: CVE-2014-0998
Reviewed by: dumbbell
MFC after: 3 days
Also, split power_suspend into power_suspend and power_suspend_early.
power_suspend_early is called before the userland is frozen.
power_suspend is called after the userland is frozen.
Currently only VT switching is hooked to power_suspend_early.
This is needed because switching away from X server requires its
cooperation, so obviously X server must not be frozen when that happens.
Freezing userland during ACPI suspend is useful because not all drivers
correctly handle suspension concurrent with other activity. This is
especially applicable to drivers ported from other operating systems
that suspend all software activity between placing drivers and hardware
into suspended state.
In particular drm2/radeon (radeonkms) depends on the described
procedure. The driver does not have any internal synchronization
between suspension activities and processing of userland requests.
Many thanks to kib for the code that allows to freeze and thaw all
userland threads.
Note that ideally we also need to park / inhibit (non-special) kernel
threads as well to ensure that they do not call into drivers.
MFC after: 17 days
suspend/resume
The goal is to avoid that the vt(4) resume happens before the video
display is resumed. The original patch was provided by Andriy Gapon.
This new patch registers the handlers in vt_upgrade(). This is done
once, thanks to the VDF_ASYNC flag. I abused this flag because it was
already abused by the keyboard allocation. The event handlers then call
the backend if it provides callbacks for suspend/resume.
Differential Revision: https://reviews.freebsd.org/D1004
On behalf of: dumbbell
MFC after: 2 weeks
which prevents us from doing a "callout_drain()" call. The callout in
question has a lock associated with it and we are not freeing the
callout. That means we can use the "callout_stop()" function to
atomically stop the callback iff the "callout_stop()" function is
called locked. This patch applies proper locking to "callout_stop()"
and replaces a "callout_drain()" with a "callout_stop()".
MFC after: 1 week
Revert the EFI part of r276064 until I can test it properly on a real EFI
system. This was causing problems to people booting using UEFI and vt.
Reported by: O. Hartmann <ohartman@zedat.fu-berlin.de>
Current VT drivers don't register the memory regions they use with the
nexus. This patch makes vt_vga and vt_efifb register the memory regions they
use.
This is needed (at least) for Xen support, since the FreeBSD kernel will try
to use the holes in the memory map to map memory from other domains and
setup it's grant table.
Sponsored by: Citrix Systems R&D
Reported by: sbruno
Tested by: emaste
Reviewed by: ray
PR: 195537
Differential Revision: https://reviews.freebsd.org/D1291
Therefore, to set histry size to 2000 lines, add the following line to
your kernel configuration file:
options SC_HISTORY_SIZE=2000
The default history remains at 500 lines.
MFC after: 1 week
The problem was that only the kbdmux keyboard index was saved in
vd->vd_keyboard. This index is -1 when kbdmux isn't used. In this
case, the keyboard was correctly allocated, but the returned index was
discarded.
PR: 194718
MFC after: 1 week
A new terminal_set_cursor() is added: it wraps the existing
teken_set_cursor() function.
In vtbuf_grow(), the cursor position is adjusted at the end of the
function. In vt_change_font(), we call terminal_set_cursor() just after
terminal_set_winsize_blank(), while the terminal is mute.
This fixes a bug where, after loading a kernel video driver which
increases the terminal window size, the cursor remains at its old
position, in other words, in the middle of the display content.
PR: 194421
MFC after: 1 week
To restore the default font using vidcontrol(1), use the "-f" flag
without an argument:
vidcontrol -f < /dev/ttyv0
PR: 193910
Differential Revision: https://reviews.freebsd.org/D971
Submitted by: Marcin Cieslak <saper@saper.info>
Reviewed by: ray@, emaste@
Approved by: ray@
MFC after: 1 week
Before, the font was loaded and the window size recalculated, giving an
unusable terminal, even if the actual font didn't change.
Reported by: beeessdee@ruggedinbox.com
MFC after: 3 days
Previously, if no drivers attached at boot we would panic with
"vtbuf_fill_locked begin.tp_row 0 must be < screen height 0".
PR: 192248
Reviewed by: ray
MFC after: 3 days
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D954
When the screen size is unknown, it's set to 0x0. We can't use that as
the buffer size, otherwise, functions such as vtbuf_fill() will fail.
This fixes a panic on RaspberryPi, where there's no vt(4) backend
configured early in boot.
PR: 193981
Tested by: danilo@
MFC after: 3 days
Add new functions to manipulate these mode & state, instead of calling
kbdd_ioctl() everyhere.
This fixes at least two bugs:
1. The state of the Scroll Lock LED and the state of scroll mode
could be out-of-sync. For instance, if one enables scroll mode on
window #1 and switches to window #2, the LED would remain on, but
the window wouldn't be in scroll mode.
Similarily, when switching between a console and an X.Org
session, the LED states could be inconsistent with the real
state.
2. When exiting from an X.Org session, the user could be unable to
type anything. The workaround was to switch to another console
window and come back.
Differential Revision: https://reviews.freebsd.org/D821
Reviewed by: ray@
Approved by: ray@
Tested by: kwm@
MFC after: 3 days
It's now possible to scroll up the 500 hard-coded lines of history, not
just a fraction of them. For instance, one can reach the top of the boot
process.
Sometimes, when scrolling or when changing the screen size (by changing
the font or loading a KMS driver for instance), one could see the
history cycling (old content appeared below latest lines). This is
fixed.
Now, when the resolution changes are more lines can be shown, the
displayed area is adjusted so that, if the screen was filled with
content before, it's filled with content after as well: more history
is visible, instead of having blank lines below the previously visible
content.
MFC after: 3 days
reboot/halt/debug.
o Add support for most key combinations supported by syscons(4).
Reviewed by: dumbbell, emaste (prev revision of D747)
MFC after: 5 days
Sponsored by: The FreeBSD Foundation
This fixes a bug where scroll lock would not work for tty #0 when using
vt_vga's textmode. The reason was that this window is created with a
static 256x100 buffer, larger than the real size of 80x25.
Now, in vt_change_font() and vt_compute_drawable_area(), we still
perform operations even of the window has no font loaded (this is the
case in textmode here vw->vw_font == NULL). One of these operation
resizes the buffer accordingly.
In vt_compute_drawable_area(), we take the terminal size as is (ie.
80x25) for the drawable area.
The font argument to vt_set_border() is removed (it was never used) and
the code now uses the computed drawable area instead of re-doing its own
calculation.
Reported by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
Tested by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de>
MFC after: 3 days
There were two issues:
1. The area given to vt_is_cursor_in_area() was adding the drawable
area offset, something already handled by this function.
2. The cursor was shifted on the screen by the offset of this area
and thus was misplaced or not erased. Furthermore, when reaching
the bottom or right borders, the cursor was either totally
removed or not erased correctly.
MFC after: 1 week
The timer is restarted whenever a window buffer is marked as dirty or
the mouse cursor moves.
There's still room for improvement. For instance, we should not mark a
window buffer as dirty when this window isn't displayed.
Review: https://reviews.freebsd.org/D683
Reviewed by: ray@
Approved by: ray@
MFC after: 1 week
They are used when a panic occurs or when entering a DDB session for
instance.
cngrab() forces a vt-switch to the console window, no matter if the
original window is another terminal or an X session. However, cnungrab()
doesn't vt-switch back to the original window currently.
MFC after: 1 week
With the current implementation, this allows an X11 server to tell
the console it switches a particular window in "graphics mode". This
information is used by the mouse handling code to ignore sysmouse events
in the window taken by the X server: only him should receive those
events.
Reported by: flo@, glebius@, kan@
Tested by: flo@
Reviewed by: kan@
MFC after: 1 week
... not just the visible part.
This fixes a bug where, when switching from eg. vt_vga to vt_fb (ie. the
resolution goes up), the originally hidden, uninitialized area of the
buffer is displayed on the screen. This leads to a missing text cursor
when it's over an unitialized area.
This was also visible when selecting text: the uninitialized area was
not highlighted.
Internally, this area was zeroed: characters were all 0x00000000,
meaning the foreground and background color was black. Now, everything
is filled with a space with a gray foreground color, like the visible
area.
While here, remove the check for the mute flag and always use
TERMINAL_NORM_ATTR as the character attribute (ie. gray foreground,
black background).
MFC after: 1 week
This allows backends to verify they do not draw outside of this area.
This fixes a bug in vt_vga where the text was happily drawn over the
right and bottom margins, when using the Gallant font.
MFC after: 1 week
... not the whole screen. Don't use font offsets in
vt_mark_mouse_position_as_dirty().
This fixes a bug where the mouse position wasn't marked as dirty when
approaching the borders of the drawn area.
MFC after: 1 week
This fixes a "General protection fault" in vt_vga, where
vt_is_cursor_in_area() erroneously reported that the cursor was over the
text. This led to negative integers stored in "unsigned int" and chaos.
MFC after: 1 week
It's replaced by vd_bitblt_text_t, which gives more context to the
backend and allows it to perform more efficiently when redrawing a given
area.
MFC after: 1 week
There were situations where the cursor was not erased/redrawn or its
position was marked as dirty even though it's not displayed. The code is
now more straightforward.
At the same, add a function to determine if the cursor covers a given
area. This is used by backends to know if they need to draw the cursor.
This new function should be paired with a new state in struct vt_device,
called vd_mshown, which indicates if the cursor should be displayed.
This again simplifies vd_bitblt_text_t callback's API.
MFC after: 1 week
In textmode, no font is loaded, thus the page fault in
vt_mark_mouse_position_as_dirty() when it wants the font width/height.
For now, create a fake area for the textmode. This needs to be modified
if vt_vga gains mouse support in textmode.
While here, fix a build failure when SC_NO_CUTPASTE is defined:
vt_mark_mouse_position_as_dirty() must not be included in this case.
MFC after: 1 week
This fixes a bug where vga_get_cp437() was called with an invalid
argument. The screen was then filled with '?' instead of the actual
character.
MFC after: 1 week
After some testing, it appears that acquiring the lock once and keeping
it longer is slower than taking it multiple times.
While here, fix a typo in another comment.
MFC after: 1 week
The previous global offset, based on the last loaded font, had no
meaning for other windows. This caused a shifted text area, often partly
out-of-screen.
MFC after: 1 week
This fixes a bug when two windows use different fonts, but a longer-term
solution is required. The dirty area should be stored as pixels, not
character cells, because such coordinates don't have the same meaning in
all windows, when using different fonts.
MFC after: 1 week
Compared to the deprecated vd_bitbltchr_t callback, vd_bitblt_text_t
receives:
o the whole text buffer
o the dirty area
o the mouse cursor (map, position, colors)
This allows the backend to perform optimization on how to draw things.
The goal is to remove vd_bitbltchr_t and vd_putchar_t, once all driver
are converted (only vt_vga is included in this commit).
In vt_vga, this allows to draw the text and the cursor in one pass,
without ever reading from video memory (because it has all the context).
The main benefit is the speed improvement: no more slideshow during
boot!
Other bugs fixed in vt_vga are:
o left-most characters are drawn properly (the left-most pixels were
missing with bold characters and some wide letters such as 'm')
o no more black square around the cursor
o no cursor flickering when the text is scrolling
There are still many problems to fix: the known issues are marked with
"FIXME" inside the code.
MFC after: 1 week
The goal is to clear the video memory, in case an application drew to
it. So the content shouldn't be loaded in the latches, it can't be
trusted anyway.
This improves a bit the window switch speed.
MFC after: 1 week
At the same time, "w" and "h" members are now called "width" and
"height". The goal is to have a more "public" structure, because it will
soon be passed as argument to a new callback, replacing vd_bitbltchr_t.
MFC after: 1 week
Later, we just see if the "struct mouse_cursor" pointer is set. This
avoids the need to mess with all the conditions several times; this has
been error prone.
While here, rename the variable "m" to a more meaningful "cursor", like
it's done elsewhere in the code.
MFC after: 1 week
This fixes bad looking refresh when switching window: squares instead
of text, flashing screen, and so on. In the worst case, vt_flush() came
at a very inappropriate timing and the screen was not refreshed at all
(leaving squares all over the place).
This doesn't fix the flickering of the screen with vt_vga, because the
sync signal is temporarily stopped and the video memory is cleared.
MFC after: 1 week
Like r270273, this has no effect for now, because the cursor is always
drawn. This is in preparation of future changes to vd_bitbltchr_t API.
MFC after: 1 week
Currently, this has no effect, because the cursor is always redrawn
anyway. But this will be useful after improvements to the vd_bitbltchr_t
callback API.
The vt_device structure members used to store the position of the cursor
as of the last redraw are renamed from vd_mdirty{x,y} to vd_mold{x,y}.
The associated comment is fixed too. Also, their value is now expressed
in pixels, not in character columns/row.
MFC after: 1 week
This avoids unnecessary redraw. In particular, during boot, where the
cursor is disabled and its fake position is [0;0], this triggered a
refresh of the whole screen each time vt_flush() is called.
MFC after: 1 week
Before the global flag was set/unset using the CONS_MOUSECTL ioctl, and
the per-window flag through the MOUSE_SETLEVEL or MOUSE_SETMODE ioctls.
Also, if the cursor is already enabled/disabled, return immediatly. This
avoids to reset the cursor's position to the center of the screen.
This matches syscons' behavior.
While here, remove a trailing space and a redundant variable
declaration.
Rename vt_generate_vga_palette() to vt_generate_cons_palette() and
change it to build a palette where the color index is the same than in
terminal escape codes, not the VGA index. That's what TCHAR_CREATE()
uses and passes to vt(4).
The main differences between both orders are:
o Blue and red are swapped (1 <-> 4)
o Yellow and cyan are swapped (3 <-> 6)
The problem remained unnoticed, because the RGB bit indexes passed to
vt_generate_vga_palette() were reversed. This inversion was cancelled
by the colors inversions in the generated palette. For instance, red
(0xff0000) and blue (0x0000ff) have bytes in opposite order, but were
swapped in the palette. But after changing the value of blue (see last
paragraph), the modified color was in fact the red one.
This commit includes a fix to creator_vt.c, submitted by Nathan
Whitehorn: fb_cmsize is set to 16. Before this, the generated palette
would be overwritte. This fixes colors on sparc64 with a Creator3D
adapter.
While here, tune the palette to better match console colors and improve
the readability (especially the dark blue).
Submitted by: nwhitehorn (fix to creator_vt.c)
MFC after: 1 week
In several functions, vtbuf_putchar() in particular, the lock on vtbuf
is acquired twice:
1. once by the said functions;
2. once in vtbuf_dirty().
Now, vtbuf_dirty_locked() and vtbuf_dirty_cell_locked() allow to
acquire that lock only once.
This improves the input speed of vt(4). To measure the gain, a
50,000-lines file was displayed on the console using cat(1). The time
taken by cat(1) is reported below:
o On amd64, with vt_vga:
- before: 1.0"
- after: 0.5"
o On sparc64, with creator_vt:
- before: 13.6"
- after: 10.5"
MFC after: 1 week
the right register bank for the framebuffer. Disable the assigned-addresses
path on SPARC since it is just a hack for IBM PPC systems and was neither
relevant for nor worked on SPARC anyway.
framebuffer drivers. This lets ofwfb work with xf86-video-scfb and makes
the driver much more generic and less PCI-centric. This changes some
user-visible behavior and will require updates to the xorg-server port
on PowerPC when using ATI graphics cards.
This change is a bit ugly, but so is the coupling between the i915
driver and syscons. It isn't worth developing a more elegant solution
only to support the legacy syscons console.
